Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > "static" prefix - to parallel "this" prefix

Reply
Thread Tools

"static" prefix - to parallel "this" prefix

 
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-08-2004
Chris Uppal wrote:
>>>The name of the class.

>>
>>But you're not specifying the name of the class here. You're specifying
>>the context of the variable in question. That it just happens to *also*
>>be the classname is just a coincidence, and doing that doesn't harm the
>>code or the intention at all.

>
> Most of the uses of the classname are redundant. To see that, change the name
> of the class. All the uses of the classname (within the body of the class)
> that have to change with it are redundant.


Change the name of an instance variable. All the uses of the variable
(within the body of the class if not the clients of the class) that have
to change with it are redundant.

My point is, it's no more a case of redundancy than any other example of
indicating context. You use the classname to indicate the context in
which you're using the static variable.

BTW, the above scenario doesn't happen in Eclipse: you refactor and
rename the class and all of those references are updated. *AND* the
references in *other* classes are updated too. Which brings up an
interesting question: how will you refer to static methods/variables in
*other* classes? Are we going to keep the ClassName.staticField pattern?
If so, then we now have *two* ways of doing the *exact same thing* which
to my mind makes the static keyword even *less* attractive.

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
 
 
 
Tim Tyler
Guest
Posts: n/a
 
      12-08-2004
Darryl L. Pierce <(E-Mail Removed)> wrote or quoted:
> Chris Uppal wrote:


> >>>The name of the class.
> >>
> >>But you're not specifying the name of the class here. You're specifying
> >>the context of the variable in question. That it just happens to *also*
> >>be the classname is just a coincidence, and doing that doesn't harm the
> >>code or the intention at all.

> >
> > Most of the uses of the classname are redundant. To see that, change
> > the name of the class. All the uses of the classname (within the
> > body of the class) that have to change with it are redundant.

>
> Change the name of an instance variable. All the uses of the variable
> (within the body of the class if not the clients of the class) that have
> to change with it are redundant.


Nonsense: they say which variable you are talking about.

Within the definition of a class you shouldn't need to spell out
the name of the class - you /should/ just be able to say "this class".

> BTW, the above scenario doesn't happen in Eclipse: you refactor and
> rename the class and all of those references are updated. *AND* the
> references in *other* classes are updated too. Which brings up an
> interesting question: how will you refer to static methods/variables in
> *other* classes? Are we going to keep the ClassName.staticField pattern?
> If so, then we now have *two* ways of doing the *exact same thing* which
> to my mind makes the static keyword even *less* attractive.


Actually there would be three ways:

"ClassName.var"
"var"
....or...
"static.var".

They don't say quite the same thing as each other - though they
would all refer to the same static variable.
--
__________
|im |yler http://timtyler.org/ http://www.velocityreviews.com/forums/(E-Mail Removed) Remove lock to reply.
 
Reply With Quote
 
 
 
 
Tim Tyler
Guest
Posts: n/a
 
      12-08-2004
Chris Uppal <(E-Mail Removed)-this.org> wrote or quoted:

> I agree that a Smalltalk-like class concept would be far preferable to
> the Java model (which achieves neither clarity nor simplicity nor
> flexibility -- i.e. it's a looser). But I can't see that ever
> happening, as you say, to much inertia. But I don't think it's a very
> good idea to try to make the Java model look like the ST one with
> "tricks" like allowing "this" in static contexts. IMO, it would cause
> more confusion than it saves. "The whole hog or none" seems to apply here.


Java's "static" context is an irregularitly - and an unnecessary one.

If - for whatever arcane security reason, class members can't be
associated directly with the class objects, they ought at least to
be associated with *some* object.

Otherwise you wind up with the Java situation - where there's a
whole bunch of extra material in the JLS to deal specifically
with static entities, how they are (or aren't) inherited - what
happens when a member variable overrides a static one in an
inherited class - and so on - all pointless irregularity that
makes the langage harder to learn, and makes parsers and compilers
more difficult to write.
--
__________
|im |yler http://timtyler.org/ (E-Mail Removed) Remove lock to reply.
 
Reply With Quote
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-09-2004
Tim Tyler wrote:
>>>Most of the uses of the classname are redundant. To see that, change
>>>the name of the class. All the uses of the classname (within the
>>>body of the class) that have to change with it are redundant.

>>
>>Change the name of an instance variable. All the uses of the variable
>>(within the body of the class if not the clients of the class) that have
>>to change with it are redundant.

>
> Nonsense: they say which variable you are talking about.
>
> Within the definition of a class you shouldn't need to spell out
> the name of the class - you /should/ just be able to say "this class".


You don't *have* to mention the class *except* to clarify the context,
just as you do when you use the "this" keyword. If using the classname
is "redundant" then so would using "static" and "this" since they are
used *for* the *same* reason: to clarify for the compiler the *specific*
variable to which you're referring when there's ambiguity in the usage.

>>BTW, the above scenario doesn't happen in Eclipse: you refactor and
>>rename the class and all of those references are updated. *AND* the
>>references in *other* classes are updated too. Which brings up an
>>interesting question: how will you refer to static methods/variables in
>>*other* classes? Are we going to keep the ClassName.staticField pattern?
>>If so, then we now have *two* ways of doing the *exact same thing* which
>>to my mind makes the static keyword even *less* attractive.

>
> Actually there would be three ways:
>
> "ClassName.var"
> "var"
> ....or...
> "static.var".
>
> They don't say quite the same thing as each other - though they
> would all refer to the same static variable.


And how does the above tell you *which* other class you're referring to?
I asked above "how will you refer to static methods/variables in *OTHER*
(new emphasis) classes?" In this scenario "static" brings nothing new to
the table and you will *still* have to type the classname to provide
context to the compiler. So, in deference to your claiming it's
redundant data, it's actually quite necessary and there's little need to
have *two* ways to do the same thing...

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-09-2004
Tim Tyler wrote:

> Java's "static" context is an irregularitly - and an unnecessary one.
>
> If - for whatever arcane security reason, class members can't be
> associated directly with the class objects, they ought at least to
> be associated with *some* object.
>
> Otherwise you wind up with the Java situation - where there's a
> whole bunch of extra material in the JLS to deal specifically
> with static entities, how they are (or aren't) inherited - what
> happens when a member variable overrides a static one in an
> inherited class - and so on - all pointless irregularity that
> makes the langage harder to learn, and makes parsers and compilers
> more difficult to write.


That scenario is already specifically handled: the descendant class's
variable *hides* the parent class's variable, just as it would with a
method. You don't inherit static fields or methods: they are explicitly
tied to the class in which they're defined.

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-09-2004
Tim Tyler wrote:
<snip>

Also, I wanted to mention that in the below code:

public class FooParent
{
public static String bar = "parent";
}

public class FooChild extends FooParent
{
public static String bar = "child";
}

public class FooTest
{
public static void main(String[] args)
{
FooParent foo = new FooChild();

System.out.println(foo.bar);
}
}

the output is "parent" because the *reference* is to a FooParent
reference and so the compiler resolves the static reference to the class
variable for *that* type.

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      12-09-2004
Tim Tyler wrote:

> Otherwise you wind up with the Java situation - where there's a
> whole bunch of extra material in the JLS to deal specifically
> with static entities, how they are (or aren't) inherited - what
> happens when a member variable overrides a static one in an
> inherited class - and so on - all pointless irregularity


Oh, I agree entirely.

> that makes the langage harder to learn


and use.

-- chris



 
Reply With Quote
 
Tim Tyler
Guest
Posts: n/a
 
      12-09-2004
Darryl L. Pierce <(E-Mail Removed)> wrote or quoted:
> Tim Tyler wrote:


> > Java's "static" context is an irregularitly - and an unnecessary one.
> >
> > If - for whatever arcane security reason, class members can't be
> > associated directly with the class objects, they ought at least to
> > be associated with *some* object.
> >
> > Otherwise you wind up with the Java situation - where there's a
> > whole bunch of extra material in the JLS to deal specifically
> > with static entities, how they are (or aren't) inherited - what
> > happens when a member variable overrides a static one in an
> > inherited class - and so on - all pointless irregularity that
> > makes the langage harder to learn, and makes parsers and compilers
> > more difficult to write.

>
> That scenario is already specifically handled: the descendant class's
> variable *hides* the parent class's variable, just as it would with a
> method. You don't inherit static fields or methods: they are explicitly
> tied to the class in which they're defined.


I didn't claim that it didn't work - or that I didn't know how it
worked.

My claim is that the specification of how static objects behaves
is irregular, needs explicit support from the JLS, and makes the
language harder to learn, parse and use.

In particular, sections:

http://java.sun.com/docs/books/jls/s...doc.html#37544
http://java.sun.com/docs/books/jls/s...oc.html#229128
http://java.sun.com/docs/books/jls/s...oc.html#246853
http://java.sun.com/docs/books/jls/s...doc.html#39245

....are largely unnecessary.

Smalltalk has an altogether more sensible approach: "static" methods are
ordinary instance methods of the object representing the class.
--
__________
|im |yler http://timtyler.org/ (E-Mail Removed) Remove lock to reply.
 
Reply With Quote
 
Tim Tyler
Guest
Posts: n/a
 
      12-09-2004
Darryl L. Pierce <(E-Mail Removed)> wrote or quoted:
> Tim Tyler wrote:


> >>>Most of the uses of the classname are redundant. To see that, change
> >>>the name of the class. All the uses of the classname (within the
> >>>body of the class) that have to change with it are redundant.
> >>
> >>Change the name of an instance variable. All the uses of the variable
> >>(within the body of the class if not the clients of the class) that have
> >>to change with it are redundant.

> >
> > Nonsense: they say which variable you are talking about.
> >
> > Within the definition of a class you shouldn't need to spell out
> > the name of the class - you /should/ just be able to say "this class".

>
> You don't *have* to mention the class *except* to clarify the context,
> just as you do when you use the "this" keyword.


Constructors are the most common mention of class names in the same
class. They replicate the name of the class at several places
within the class. The only alternative is not to use constructors
- and then you lose out on the inherited constructor from
Object - and implicit calls to super().

> >>BTW, the above scenario doesn't happen in Eclipse: you refactor and
> >>rename the class and all of those references are updated. *AND* the
> >>references in *other* classes are updated too. Which brings up an
> >>interesting question: how will you refer to static methods/variables in
> >>*other* classes? Are we going to keep the ClassName.staticField pattern?
> >>If so, then we now have *two* ways of doing the *exact same thing* which
> >>to my mind makes the static keyword even *less* attractive.

> >
> > Actually there would be three ways:
> >
> > "ClassName.var"
> > "var"
> > ....or...
> > "static.var".
> >
> > They don't say quite the same thing as each other - though they
> > would all refer to the same static variable.

>
> And how does the above tell you *which* other class you're referring to?


It doesn't. I never said it did. I was just pointing out that the
claim that there were *two* ways of doing things was incorrect:

Actually two ways is the current situation - so your argument boils down
to an assertion that the current situation is undesirable

> I asked above "how will you refer to static methods/variables in *OTHER*
> (new emphasis) classes?"


The same as normal. The proposal has nothing to do with that.

> In this scenario "static" brings nothing new to the table [...]


It deals with the situation where you are distingishing instance
variables, local variables and static variables in the *same* class.

The proposal was never supposed to improve the situation with other
classes.

It is analogous to "this" in that respect.

> and you will *still* have to type the classname to provide
> context to the compiler. So, in deference to your claiming it's
> redundant data, it's actually quite necessary [...]


You should not have to spell out the class name repeatedly in
the class. Doing so is redundant - and it's a maintenance screw-up -
since you open up the possibility of the names getting out of step. You
/should/ be able to say something which says "this class".

In a sensible language, you'd just use the class object: "class" -
but of course in Java, this doesn't work.
--
__________
|im |yler http://timtyler.org/ (E-Mail Removed) Remove lock to reply.
 
Reply With Quote
 
Darryl L. Pierce
Guest
Posts: n/a
 
      12-09-2004
Tim Tyler wrote:

>>>Within the definition of a class you shouldn't need to spell out
>>>the name of the class - you /should/ just be able to say "this class".

>>
>>You don't *have* to mention the class *except* to clarify the context,
>>just as you do when you use the "this" keyword.

>
> Constructors are the most common mention of class names in the same
> class. They replicate the name of the class at several places
> within the class. The only alternative is not to use constructors
> - and then you lose out on the inherited constructor from
> Object - and implicit calls to super().


So? What does that have to do with the topic of using the classname to
specify context?

>>>>BTW, the above scenario doesn't happen in Eclipse: you refactor and
>>>>rename the class and all of those references are updated. *AND* the
>>>>references in *other* classes are updated too. Which brings up an
>>>>interesting question: how will you refer to static methods/variables in
>>>>*other* classes? Are we going to keep the ClassName.staticField pattern?
>>>>If so, then we now have *two* ways of doing the *exact same thing* which
>>>>to my mind makes the static keyword even *less* attractive.
>>>
>>>Actually there would be three ways:
>>>
>>>"ClassName.var"
>>>"var"

>>
>> > ....or...
>> > "static.var".
>> >
>> > They don't say quite the same thing as each other - though they
>> > would all refer to the same static variable.

>>
>>And how does the above tell you *which* other class you're referring to?

>
> It doesn't. I never said it did.


Then why did you write it in reply to my question? I asked a specific
question: how will you specify the context for a static variable or
field in a *different* class from the one referring to it?

> I was just pointing out that the
> claim that there were *two* ways of doing things was incorrect:


A claim *I* never made. I said that you use the classname to specify
context in an ambiguous piece of code. I never said there were only two
ways to resolving this.

> Actually two ways is the current situation - so your argument boils down
> to an assertion that the current situation is undesirable


No, it doesn't. My position is that the way it's done now is perfectly
acceptable and that there's no need for a new keyword to specify what is
already quite clearly stated by using the class's name for a static
reference.

>>I asked above "how will you refer to static methods/variables in *OTHER*
>>(new emphasis) classes?"

>
> The same as normal. The proposal has nothing to do with that.


The proposal, then, is unnecessary. Why do we need a *special* keyword
to state what is *already* possible and clearly stated with the existing
language specification?

>>In this scenario "static" brings nothing new to the table [...]

>
> It deals with the situation where you are distingishing instance
> variables, local variables and static variables in the *same* class.


Something that is *already* done by using the name of the class. As I
said, "static" brings nothing _new_ to the table.

> The proposal was never supposed to improve the situation with other
> classes.
>
> It is analogous to "this" in that respect.


Except that "this" has a specific purpose that is not available
otherwise. "static" doesn't do anything new or special, and the existing
way to do it (what you've called "redundant") will *still* have to be
available so that ClassA can refer to ClassB.SOME_STATIC_FIELD.

>>and you will *still* have to type the classname to provide
>>context to the compiler. So, in deference to your claiming it's
>>redundant data, it's actually quite necessary [...]

>
> You should not have to spell out the class name repeatedly in
> the class. Doing so is redundant - and it's a maintenance screw-up -
> since you open up the possibility of the names getting out of step. You
> /should/ be able to say something which says "this class".


You're repeating yourself without supporting your statement. The fact
is, you *don't* _have_ to "spell out the class name" at
*all*....provided you give your static field or method a name *different
from* an instance field/method and a parameter name. If you want to use
the same name for a static field as a passed parameter, then you have to
accept that you'll need to specify the context for the static field by
using the classname to specify context. Changing the language spec to
add a new keyword is rather daft since it doesn't prevent the underlying
problem, which is the poor choice of variable names.

> In a sensible language, you'd just use the class object: "class" -
> but of course in Java, this doesn't work.


The programming language will never be able to stop programmers from
making poor choices.

--
Darryl L. Pierce <(E-Mail Removed)>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Parallel in, Parallel out shift register Vivek Menon VHDL 0 06-10-2011 10:15 PM
Parallel in, Parallel out shift register Vivek Menon VHDL 5 06-08-2011 03:56 PM
Parallel port control with USB->Parallel converter Soren Python 4 02-14-2008 03:18 PM
removing a namespace prefix and removing all attributes not in that same prefix Chris Chiasson XML 6 11-14-2006 05:08 PM
ISE 6.3i error : unable to find flow prefix Nisheeth VHDL 0 03-08-2005 05:57 PM



Advertisments