Best way to halt Java process?
in [Java Programming]
|
Prev: encrypted javamail MimeMultipart
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, 2.ITIM-TAM Analyst, 3. IT Project Coordinator / Project Analyst
From: Andreas Leitgeb on 16 Jun 2010 07:19 Mike Schilling <mscottschilling(a)hotmail.com> wrote: > "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message > news:hv9kgf$j4c$1(a)news.eternal-september.org... >> On Sat, 12 Jun 2010 21:27:51 -0700, Mike Schilling wrote: >>> "ClassCastException" <zjkg3d9gj56(a)gmail.invalid> wrote in message >>> news:hv1kf6$rdk$1(a)news.eternal-september.org... >>>> Let me clarify: a global mutable error flag that isn't actually >>>> supposed to change more than once is an ugly hack to work around the >>>> lack of something like init(), had it proved to be lacking. >>> You insist on calling a private instance field "global". >> If you write a program with a mutable field visible throughout the entire >> program, then I consider it to be a global even if it's because your >> program consists of a one-instance class with an instance field. > You can consider it whatever you like, but you'll be alone. Having code like: enum Foo { THE_INSTANCE; public int my_non_static_var; } makes "Foo.THE_INSTANCE.my_non_static_var" equivalent to a static with respect to most of the up- and downsides of real static variables or global variables in C/C++. That's how I understand CCE's point. I do not claim, that it was relevant in the context, where the field was contained in some non-static Session-object, which is quite a different thing.
From: Lew on 16 Jun 2010 07:41 ClassCastException wrote: >>> If you write a program with a mutable field visible throughout the entire >>> program, then I consider it to be a global even if it's because your >>> program consists of a one-instance class with an instance field. Mike Schilling wrote: >> You can consider it whatever you like, but you'll be alone. Andreas Leitgeb wrote: > Having code like: > enum Foo { > THE_INSTANCE; > public int my_non_static_var; > } > makes "Foo.THE_INSTANCE.my_non_static_var" equivalent to a static > with respect to most of the up- and downsides of real static "most" != all, and the (misnamed) 'my_non_static_var' is still not global. For one thing, if there are more than one enum constant, there will be more than one 'my_non_static_var'. "Global" != "shared". > variables or global variables in C/C++. > > That's how I understand CCE's point. There no doubt is a valid point in there somewhere, but to communicate it one must use the language of the community. The /Princess Bride/ and /Through the Looking-Glass/ quotes upthread should have illuminated that point. > I do not claim, that it was relevant in the context, where the > field was contained in some non-static Session-object, which > is quite a different thing. There are dangers in shared variables, but that doesn't make them global. Even if CCE's point had been relevant, it was still misstated. Instead of making his point, he cause a shi*storm over the wrong terminology. Use the right words. There's glory for you. -- Lew
From: Andreas Leitgeb on 16 Jun 2010 11:38 > Andreas Leitgeb wrote: >> Having code like: >> enum Foo { >> THE_INSTANCE; >> public int my_non_static_var; >> } >> makes "Foo.THE_INSTANCE.my_non_static_var" equivalent to a static >> with respect to most of the up- and downsides of real static Lew <noone(a)lewscanon.com> wrote: > "most" != all, and the (misnamed) 'my_non_static_var' is still not global. > For one thing, if there are more than one enum constant, there will be more > than one 'my_non_static_var'. "Global" != "shared". "global" is no Java concept in the first place. Java doesn't have global variables. Even static members of public toplevel classes do not share *all* of the properties of C/C++'s *global* variables. C/C++'s global variables are generally frowned upon for a certain property they have: *implicit* sharedness. Exactly that property is also on any field of any object whose reference happens to be accessibly stored in any static field. It seems perfectly valid to me to call non-static fields of statically reachable objects "global-like", "globals under aliasname", "globals through the backdoor", etc. > There no doubt is a valid point in there somewhere, but to communicate it one > must use the language of the community. The /Princess Bride/ and /Through the > Looking-Glass/ quotes upthread should have illuminated that point. Humpty-dumpty does a good job of spelling out, what *everyone* actually and inevitably does. And Alice does a good job of identifying the crucial words, rather than just writing off humpty-dumpty as a crackpot ;-) > There are dangers in shared variables, but that doesn't make them global. And by "global" you mean exactly that which you mean "global" to mean. ;)
From: ilan on 20 Jun 2010 16:56 Lew <lew(a)lewscanon.com> writes: > ilan wrote: >>>>>> But it seems that maybe I don't have a clear understanding of what you >>>>>> mean by the "interpretation" of the "formal" part. >>>>>> >>>>>> What do you mean? > > Lew wrote: >>>>> Pretty much the same thing we mean when we interpret the results of a >>>>> computer program in terms of the human world. > > ilan wrote: >>>> Is this interpretation "in terms of the real world" specified by formal >>>> logic? Because I was refering to this interpretation - and I had no idea >>>> you had intended this interpretation was formally defined. I am still >>>> not sure you meant that. Did you? > > Lew wrote: >>> Well under five minutes of research illuminates the knowledge gap. >>> <http://en.wikipedia.org/wiki/Interpretation_(logic)> >> > > ilan wrote: >> Huh? Thats what you meant? You interpret java programs as desribed in >> this link? >> >> Really? > > Wow. > > Wow. > > I provided that link in direct response to your question about what > interpretation was in the context of formal logic since you seemed > ignorant of what that was. How ironic. > > You and I both interpret computer programs in that way. Actually neither of us I do. > > Computer programs, from a perspective expressed upthread, are > statements of a formal logic. It was also stated upthread that > computer programs and formal logic have no meaning. That is not > true. They have meaning through their interpretation. Unfortunately, it is "not true" the most of the time only in theory and it is true most of the time in practice that they have no understood meaning since no one has successfully defined a dynamic semantic interpretaion for Java by any of three main approaches. Scheme is one of the languages for which a formal semantic interpretation has been successfully created. So some people interpret Scheme that way. Java is not one of the languages. No complete operational, denotational or axiomatic semantics have been created for Java. > > I really don't know how to be any clearer. Sorry. Please stop asking > the same question again and again. I won't ask you again. -- ilAn
From: Lew on 20 Jun 2010 17:38
On 06/20/2010 04:56 PM, ilan wrote: > Unfortunately, it is "not true" the most of the time only in theory and > it is true most of the time in practice that they have no understood > meaning since no one has successfully defined a dynamic semantic > interpretaion for Java by any of three main approaches. Scheme is one of > the languages for which a formal semantic interpretation has been > successfully created. So some people interpret Scheme that way. > > Java is not one of the languages. No complete operational, denotational > or axiomatic semantics have been created for Java. > "No true Scotsman." We *were* talking about interpretation of individual computer programs. Suddenly now you're talking about a "complete operational, denotational or axiomatic semantic" for the Java language as a whole, about which I have no claims. -- Lew |