«

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.

I never said that you didn't. I said that the language specification
specifically says how that *will* be handled. The way it's handled is
not an accident, it's an intentional situation.

<snip>

--
Darryl L. Pierce <>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard

Tim Tyler wrote:
> 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.

Sorry I didn't include this part earlier.

The way it's handled in the language specification now is clear and
logical. It's not a kludge to cover up an underlying problem; it's a
clarification that is part of what a language specification is intended
to do.

When you're dealing with static fields or methods, you're not dealing
with instances. As such, you can't have one class being used
polymorphically as another class. The only that that's polymorphic are
*OBJECTS*, not classes.

So, if you have FooParent with a static field named bar, and you create
a child class named FooChild that has its own static field named bar,
there is *no relationship* between the two static fields. That the JLS
says FooChild.bar will hide FooParent.bar is a case of the JLS avoiding
what could be an *ambiguous* situation for *compiler developers*.

<snip URLs>

> Smalltalk has an altogether more sensible approach: "static" methods are
> ordinary instance methods of the object representing the class.

And that makes no sense since static methods in Java are *not a part of
any object*. The fact that you put the word static into quotes should
have been a signal to you that something was amiss in your statement;
i.e., that Smalltalk has something that's not static from Java's point
of view doesn't mean the Smalltalk solution is what would work for Java.

--
Darryl L. Pierce <>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard

Tim Tyler wrote:
> The only alternative is not to use constructors
> - and then you lose out on the inherited constructor from
> Object - and implicit calls to super().

Please explain these assertions. (i) If you don't write a constructor
you get a default constructor with package access. (ii) Any constructor
which doesn't call super(...) gets a default super() call built into it.
(iii) I don't understand 'you lose out on the inherited constructor from
Object' at all.

Darryl L. Pierce <> wrote or quoted:
> 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?

It has to do with this - which was the context until this message,
where it was snipped out.

``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.''

> >>>>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 didn't. I wrote it in reply to:

``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.''

The answer to your question seemed so self-evident I treated it as
rhetorical.

> 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?

Exactly the same as before. The proposal has nothing whatsoever to do
with that.

> > 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.

There are at least two ways - with or without my proposal. Observing
that there are at least two ways would have been irrelevant to the
proposal.

> > 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. [...]

I /thought/ you were just arguing that having two ways of specifying
a static member was 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.
>
> 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?

Becasue it can clarifies which variable is being referred to
when the reference is in the same class.

> >>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.

This has already been discussed twice. Using the name of the class
in the same class causes refactoring pain, and leads to reduced
readability when the class name is long.

> > 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. [...]

Not "except" - because that's a different 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".
>
> 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. [...]

The whole idea of using lint tools in this context is that you add
the "this.", "static." (if available) identifiers at *every* single
location they are used - so you can identify static and instance
variables immediately by looking at them. You do not only add them in
*some* places - that would not produce the same result. You add them
*everywhere* - and use the lint tool to automatically check that they are
used in all the correct places.

> 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.

I don't have to accept it passively. I can request improvements,
that would eliminate this need.

> 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.

IMO, the underlying problem is the existence of a static context -
as opposed to class members and methods. This fudge is being
requested because static methods were always a crude and primitive hack.

> > 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.

Maybe not - but IMO, this thread isn't about doing that.
--
__________
|im |yler http://timtyler.org/ Remove lock to reply.

Darryl L. Pierce <> wrote or quoted:
> Tim Tyler wrote:

> > Smalltalk has an altogether more sensible approach: "static" methods are
> > ordinary instance methods of the object representing the class.
>
> And that makes no sense since static methods in Java are *not a part of
> any object*. [...]

To argue that Smalltalk's approach is not better you would have to point
out some advantage to Java's approach. Saying Java does things
differently is not a counter-argument - when the /way/ in which it does
things differently is the very thing that is under criticism.

> The fact that you put the word static into quotes should
> have been a signal to you that something was amiss in your statement;

I put the word in quotes because Smalltalk doesn't call analogous
methods "static".

AFAICS, there was nothing amiss in my statement.

> i.e., that Smalltalk has something that's not static from Java's point
> of view doesn't mean the Smalltalk solution is what would work for Java.

I said "Smalltalk has an altogether more sensible approach".

I don't pretend this approach could be grafted back on to Java -
especially not at this late date.

However: offering "static" methods - and failing to offer "class"
methods or class inheritance originally was almost certainly a bad
design decision - since static methods can't be overriden, add
complexity to the language, and lead to practical problems such
as the "Inherited Java Singleton Problem".

While I don't know the details, I /expect/ it was originally done
either for the sake of security - or under time pressure.
--
__________
|im |yler http://timtyler.org/ Remove lock to reply.

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?
>
> It has to do with this - which was the context until this message,
> where it was snipped out.
>
> ``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.''

Sorry, I still disagree. Re-using the classname for specific purposes
isn't redundant. *Having* to state something that's obvious from context
is redundant. For example, if you *had* to specify the classname for
context whenever you use a static method would be redundant. If you only
do it to resolve an ambiguity then it's not redundant by any definition
of the word.

>>>>>>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 didn't. I wrote it in reply to:
>
> ``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.''

The above sentence is quite obviously talking about the proposed
solution in addition to the currently existing solution.

> The answer to your question seemed so self-evident I treated it as
> rhetorical.
>
>>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?
>
> Exactly the same as before. The proposal has nothing whatsoever to do
> with that.

The proposed solution is *unnecessary*. It doesn't clarify anything, it
doesn't do anything but use a different word to achieve an end that is
*already achievable* with the current language specification. There has
not been presented a compelling reason for why we should have another
way to do something we can already do now.

>>>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.
>
> There are at least two ways - with or without my proposal. Observing
> that there are at least two ways would have been irrelevant to the
> proposal.

Huh?

>>>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. [...]
>
> I /thought/ you were just arguing that having two ways of specifying
> a static member was undesirable.

I *am* arguing that, and have been since joining this thread. What part
of my position isn't clear enough for you? The keyword you're proposing
is unnecessary. We can already do what you want by using the classname
to specify context when necessary. The described "static" keyword doest'
do anything that the classname usage can't already do. And we would
still need to use the classname when resolving the static reference from
a different class, so if we had your proposal we would end up with two
ways of achieving one single end built into the language specification.
*THAT* is redundant.

>>>>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?
>
> Becasue it can clarifies which variable is being referred to
> when the reference is in the same class.

We can *already* do that by using the classname. We don't *need* yet
*another* way to do 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.
>>
>>Something that is *already* done by using the name of the class. As I
>>said, "static" brings nothing _new_ to the table.
>
> This has already been discussed twice. Using the name of the class
> in the same class causes refactoring pain,

No, it's not. Eclipse doesn't have a problem, and it's a single, simple
search-and-replace operation for pretty much all editors. Perhaps you
aren't using the right tool?

> and leads to reduced
> readability when the class name is long.

That, sorry to say, is an opinion and not a fact.

>>>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. [...]
>
> Not "except" - because that's a different respect.

The "this" keyword has a purpose that cannot be achieved by *any* other
means. How else would you do this?

public class Foo
{
private static Vector instances = new Vector();

public Foo()
{
instances.addElement(this);
}
}

You *can't*. It's impossible without exposing the implementation details
of the Foo class to the outside world.

>>>>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. [...]
>
> The whole idea of using lint tools in this context is that you add
> the "this.", "static." (if available) identifiers at *every* single
> location they are used - so you can identify static and instance
> variables immediately by looking at them.

Sorry, mate, but *that* is redundancy. You're using a keyword where it's
not necessary.

> You do not only add them in
> *some* places - that would not produce the same result. You add them
> *everywhere* - and use the lint tool to automatically check that they are
> used in all the correct places.

You're adding it where it's unnecessary. You're now talking about
altering the language to make it easier for a utility? That's daft.

>>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.
>
> I don't have to accept it passively. I can request improvements,
> that would eliminate this need.

And I'm free to voice my opinion, and I think that this keyword proposal
offers nothing of any value.

>>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.
>
> IMO, the underlying problem is the existence of a static context -
> as opposed to class members and methods. This fudge is being
> requested because static methods were always a crude and primitive hack.

That's your opinion. Good luck with that.

>>>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.
>
> Maybe not - but IMO, this thread isn't about doing that.

And all I have read from you has been about trying to change the
language to avoid a style problem. There wouldn't even be a *need* for
the reference if it were clear to the compiler whether you were
referring to a static variable or a method argument. If it were clear
(by using a proper naming convention, for example) then you would *not*
have to tell the compiler "this variable is the static one"....

--
Darryl L. Pierce <>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard

Tim Tyler wrote:
>>>Smalltalk has an altogether more sensible approach: "static" methods are
>>>ordinary instance methods of the object representing the class.
>>
>>And that makes no sense since static methods in Java are *not a part of
>>any object*. [...]
>
> To argue that Smalltalk's approach is not better you would have to point
> out some advantage to Java's approach. Saying Java does things
> differently is not a counter-argument - when the /way/ in which it does
> things differently is the very thing that is under criticism.

And saying that Smalltalk does it differently isn't a counter-argument
either, nor does Smalltalk doing it a different way mean that Java's way
is wrong.

>>The fact that you put the word static into quotes should
>>have been a signal to you that something was amiss in your statement;
>
> I put the word in quotes because Smalltalk doesn't call analogous
> methods "static".
>
> AFAICS, there was nothing amiss in my statement.

How is Smalltalk's way different from Java? And why do you think it's
better?

>>i.e., that Smalltalk has something that's not static from Java's point
>>of view doesn't mean the Smalltalk solution is what would work for Java.
>
> I said "Smalltalk has an altogether more sensible approach".
>
> I don't pretend this approach could be grafted back on to Java -
> especially not at this late date.
>
> However: offering "static" methods - and failing to offer "class"
> methods or class inheritance originally was almost certainly a bad
> design decision - since static methods can't be overriden, add
> complexity to the language, and lead to practical problems such
> as the "Inherited Java Singleton Problem".

Static methods aren't about inheritence. Try to move past that.

--
Darryl L. Pierce <>
Visit my webpage: <http://mcpierce.multiply.com>
"By doubting we come to inquiry, through inquiry truth."
- Peter Abelard