"static" prefix - to parallel "this" prefix

[Darryl L. Pierce]

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.

 

[Tim Tyler]

Chris Uppal wrote:

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.

 

[Tim Tyler]

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.

 

[Darryl L. Pierce]

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.

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]

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]

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.

 

[Chris Uppal]

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

 

[Tim Tyler]

Tim Tyler wrote:

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/second_edition/html/classes.doc.html#37544
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#229128
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#246853
http://java.sun.com/docs/books/jls/second_edition/html/classes.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.

 

[Tim Tyler]

Tim Tyler wrote:

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

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.

 

[Darryl L. Pierce]

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

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]

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]

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

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.

 

[Esmond Pitt]

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.

 

[Tim Tyler]

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

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.

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.

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.

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.

 

[Tim Tyler]

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.

 

[Darryl L. Pierce]

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.

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.


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.

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.

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.

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.

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.

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]

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.

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