"static" prefix - to parallel "this" prefix

[Tim Tyler]

I've been playing with the Checkstyle "Require this" check.

http://checkstyle.sourceforge.net/config_coding.html#RequireThis

This forces you to distinguish between local variables,
instance variables and static variables in you code -
buy using "this.var" for all instance variables and
"Classname.var" for all static variables. It (optionally)
does the same for all method calls.

Essentially, I like the effect - but it highlights the need
for a static prefix in Java to match the "this" prefix.

Just as "this." refers to the instance, the static
modifier would refer to the class in which it appears.

Suggested syntax would be "static.var" and "static.method()" -
instead of today's "ClassName.var" and "ClassName.method()".

The rationale is that using the class name all over the place
hinders refactoring and code readability, and violates the
prinicple of specifying each fact in one place.

I believe this change would be a backward-compatible one.

Has this been suggested before?

Does it make sense to you?

Are there any other proposals to deal with the same issue?

 

[Chris Smith]

Has this been suggested before?

Not that I'm aware of.

Does it make sense to you?

I don't agree with it. The only reason that it even comes up is that
you're refusing to use the existing language feature that allows you to
omit the qualifier on static variables that are declared in the same
class or a superclass. So, in essence, instead of simplifying syntax
you are making it more complicated.

I see use of these prefixes as adding information in places where it
doesn't make sense in the flow of program logic. The result is that I'd
much rather read code that uses unqualified access to static variables
than code that uses 'static.variableName'... though admittedly either is
preferable to 'ThisClassName.variableName' where ThisClassName is the
current class.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tim Tyler]

The only reason that it even comes up is that
you're refusing to use the existing language feature that allows you to
omit the qualifier on static variables that are declared in the same
class or a superclass. So, in essence, instead of simplifying syntax
you are making it more complicated.

I see use of these prefixes as adding information in places where it
doesn't make sense in the flow of program logic. The result is that I'd
much rather read code that uses unqualified access to static variables
than code that uses 'static.variableName'... [...]

There's a cost to doing this sort of thing in terms of verbosity.

However there are some compensating benefits:

You get to see whether a variable is a local variable, a class
variable or an instance variable whenever you look at usage of it;
it prevents you from bending your variable names out of shape by
using a naming convention to do the same thing; and it can be
checked automatically by compilers and lint tools.

Avoiding bending names out of shape is a significant concern if
those names appear in your public interface - e.g. this:

class Point {
public int m_x;
public int m_y;
}

....would be painful.

IMO: currently, the biggest win comes by using "this" to distinguish
member variables everywhere.

The corresponding approach for a) methods and b) static entities
does not appear to have such convincing benefits at the moment.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

http://checkstyle.sourceforge.net/config_coding.html#RequireThis

This forces you to distinguish between local variables,
instance variables and static variables in you code -
buy using "this.var" for all instance variables and
"Classname.var" for all static variables. It (optionally)
does the same for all method calls.

Are there any other proposals to deal with the same issue?

Try using the latest Eclipse version. It can highlight local, instance,
static and even final variables in a different color. This is probably a
better idea than uglifying your code, or introducing new language syntax.

 

[Darryl L. Pierce]

You get to see whether a variable is a local variable, a class
variable or an instance variable whenever you look at usage of it;

You get that by using the classname as well. This "static" keyword
brings nothing new to the table.

it prevents you from bending your variable names out of shape by
using a naming convention to do the same thing;

You want to change the language to avoid a bad coding convention?

and it can be
checked automatically by compilers and lint tools.

The same as using the classname.

Avoiding bending names out of shape is a significant concern if
those names appear in your public interface - e.g. this:

class Point {
public int m_x;
public int m_y;
}

....would be painful.

I never have these problems. Even when an argument is the same as a
static variable, I have no problems like the above:

public class FooRuntime
{
private static void FooMidlet instance = null;

public static void setMidletInstance(MIDlet instance)
{
FooRuntime.instance = instance;
}
}

Crystal clear exactly what I'm doing without needing a new keyword to
achieve that goal.

<snip>

 

[Tim Tyler]

Tim Tyler wrote:

You get that by using the classname as well. This "static" keyword
brings nothing new to the table.


You want to change the language to avoid a bad coding convention?


The same as using the classname.

I already indicated the problems with using the class name:

``The rationale is that using the class name all over the place
hinders refactoring and code readability, and violates the
prinicple of specifying each fact in one place.''

If the class name is a rather LongOneWithManyCharacters the approach
becomes unweildy.

I never have these problems. Even when an argument is the same as a
static variable, I have no problems like the above:

public class FooRuntime
{
private static void FooMidlet instance = null;

public static void setMidletInstance(MIDlet instance)
{
FooRuntime.instance = instance;
}
}

Crystal clear exactly what I'm doing without needing a new keyword to
achieve that goal.

You are apparently not using a convention to distinguish static, instance
and local variables - and so from my point of view it will often not
be crystal clear what is going on - without consulting the class
definition.

 

[Chris Uppal]

Suggested syntax would be "static.var" and "static.method()" -
instead of today's "ClassName.var" and "ClassName.method()". [...]
Has this been suggested before?

Does it make sense to you?

Are there any other proposals to deal with the same issue?

Yes, yes, and yes, respectively ;-)

Alex Hunsley posted a similar suggestion (maybe identical) a few months ago;
see this thread (sorry about the URL, but it seems that Google is in the
process of switching how the Google groups work):

http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/4ceda7465055571c

(in case the URL stops working, the thread's title is "Good idea or full it
it?")

Personally, I like the idea but think it would work still better with a
different keyword such as 'thisClass', see my post in the above thread for
details.

-- chris

 

[Tim Tyler]

Tim Tyler wrote:

Try using the latest Eclipse version. It can highlight local, instance,
static and even final variables in a different color. This is probably a
better idea than uglifying your code, or introducing new language syntax.

I'm using the latest stable version of Eclipse - 3.0.1.

The feature is not present there.

I see no mention of this on:

http://download.eclipse.org/downloads/drops/S-3.1M1-200408122000/Eclipse-3.1-M1-News.html
http://download.eclipse.org/downloads/drops/S-3.1M2-200409240800/eclipse-news-M2.html

....or...

http://download.eclipse.org/downloads/drops/S-3.1M3-200411050810/eclipse-news-part1-M3.html

What version of Eclipse are you using?

 

[Tim Tyler]

Tim Tyler wrote:

Suggested syntax would be "static.var" and "static.method()" -
instead of today's "ClassName.var" and "ClassName.method()". [...]
Has this been suggested before?

Does it make sense to you?

Are there any other proposals to deal with the same issue?

Yes, yes, and yes, respectively ;-)

Alex Hunsley posted a similar suggestion (maybe identical) a few months ago;
see this thread (sorry about the URL, but it seems that Google is in the
process of switching how the Google groups work):

http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/4ceda7465055571c

(in case the URL stops working, the thread's title is "Good idea or full it
it?")

Personally, I like the idea but think it would work still better with a
different keyword such as 'thisClass', see my post in the above thread for
details.

The idea of eliminating constructor names is appealing.

However, I'm not sure what syntax would be best for that.

About the only alternative I considered for "static." was "class.".

It would *have* to be an existing keyword (or a symbol?) - unless you were
prepared for name clashes with identifiers in existing code.

I also think that "this." should be available to refer to static
data within static methods - and that there should be a corresponding
static object associated with the class that is accessible to the
programmer - i.e. that Java should behave more like smalltalk,
with everything being an object - and having a "this" reference.

However that would result in much more major surgery - and Java
probably has too much inertia for that sort of surgery to be
practical at this late date.

 

[Oscar kind]

I've been playing with the Checkstyle "Require this" check.

http://checkstyle.sourceforge.net/config_coding.html#RequireThis

This forces you to distinguish between local variables,
instance variables and static variables in you code -
buy using "this.var" for all instance variables and
"Classname.var" for all static variables. It (optionally)
does the same for all method calls.

Essentially, I like the effect - but it highlights the need
for a static prefix in Java to match the "this" prefix.

Just as "this." refers to the instance, the static
modifier would refer to the class in which it appears.

No it does not. A static instance / method exists only in the class that
defines it. Not in the subclasses. That the compiler resolves them anyway
is IMHO a bug, even though it is convenient (i.e. syntactic sugar).

Remember however, that a static method does not have an instance attached
to it. It's just some random code, grouped with a class because it happens
to look nice. For a static method, there is no instance, no class, etc.
The only reason you are still "inside" a class is because of the scope of
the block the definition happens to be in.

It is of course possible to change all this, but this would create an
enormous change in the underlying structure of the language. It's easier
to create and market a new programming language than to fix the problems
this would create.

 

[Tim Tyler]

I've been playing with the Checkstyle "Require this" check.

http://checkstyle.sourceforge.net/config_coding.html#RequireThis

This forces you to distinguish between local variables,
instance variables and static variables in you code -
buy using "this.var" for all instance variables and
"Classname.var" for all static variables. It (optionally)
does the same for all method calls.

Essentially, I like the effect - but it highlights the need
for a static prefix in Java to match the "this" prefix.

Just as "this." refers to the instance, the static
modifier would refer to the class in which it appears.

No it does not. [...]

I am well aware that it doesn't *today*.

It was a *proposal* - and clearly presented as such, IMO.

A static instance / method exists only in the class that
defines it. Not in the subclasses. That the compiler resolves them anyway
is IMHO a bug, even though it is convenient (i.e. syntactic sugar).

Remember however, that a static method does not have an instance attached
to it. It's just some random code, grouped with a class because it happens
to look nice. For a static method, there is no instance, no class, etc.
The only reason you are still "inside" a class is because of the scope of
the block the definition happens to be in.

It is of course possible to change all this, but this would create an
enormous change in the underlying structure of the language. [...]

Actually the proposal would not break any existing code. FWIW, I would
describe it as a rather cosmetic change. For instance it could be
implemented quite effectively rather trivially using a preprocessor.

The only things affected would be programs that automatically parse
code - and they can be updated - as Tiger clearly demonstrated.

 

[Darryl L. Pierce]

I already indicated the problems with using the class name:

``The rationale is that using the class name all over the place
hinders refactoring and code readability, and violates the
prinicple of specifying each fact in one place.''

If the class name is a rather LongOneWithManyCharacters the approach
becomes unweildy.

How does it hinder refactoring? Search-and-replace the old class name
for the new class name in one source file and it's done. Not a problem.

And, what do you mean by "specifying each fact in one place"? Sorry, I'm
not familiar with that phrase with regards to software development. What
fact is being specified all over the place that wouldn't also be
specified all over the place by the "static" keyword?

You are apparently not using a convention to distinguish static, instance
and local variables

No, I don't. They clutter things up most of the time.

- and so from my point of view it will often not
be crystal clear what is going on - without consulting the class
definition.

The above is amazingly clear. Like any (lack of) convention, you just
have to be used to it.

 

[Darryl L. Pierce]

I'm using the latest stable version of Eclipse - 3.0.1.

The feature is not present there.

It's an advanced editing feature.

Window->Preferences->Java->Editor->Syntax->Enable advanced highlighting

 

[Tim Tyler]

Tim Tyler wrote:

How does it hinder refactoring? Search-and-replace the old class name
for the new class name in one source file and it's done. Not a problem.

That step is totally unnecessary if the class neme is not hird-wired into
the class all over the place.

Also - as I mentioned - using the name in many places in the class
hinders readability if the class name is very long.

And, what do you mean by "specifying each fact in one place"? Sorry, I'm
not familiar with that phrase with regards to software development.

Useful programming proverb: specify each fact in one place.

More realistic verion: specify each fact in as few places as possible.

What fact is being specified all over the place that wouldn't also be
specified all over the place by the "static" keyword?

The name of the class.

 

[Tim Tyler]

Tim Tyler wrote:

Suggested syntax would be "static.var" and "static.method()" -
instead of today's "ClassName.var" and "ClassName.method()". [...]
Has this been suggested before?

Does it make sense to you?

Are there any other proposals to deal with the same issue?

Yes, yes, and yes, respectively ;-)

Alex Hunsley posted a similar suggestion (maybe identical) a few months ago;
see this thread (sorry about the URL, but it seems that Google is in the
process of switching how the Google groups work):

http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/4ceda7465055571c

[...]

(in case the URL stops working, the thread's title is "Good idea or full it
it?")

Personally, I like the idea but think it would work still better with a
different keyword such as 'thisClass', see my post in the above thread for
details.

The idea of eliminating constructor names is appealing.

However, I'm not sure what syntax would be best for that.

Something regular would be best - IMO.

I think I favour a Smalltalk-style factory method:

ClassName c = ClassName.new(); // construct...

class ClassName {
ClassName new() { ... } // constructor...
}

This is more regular than having dedicated constructor syntax -
I would think. I doesn't deal with the class name, though -
unless you allow: "static new()".

Of course Java is far too frozen for this sort of thing as well.

 

[Tim Tyler]

Tim Tyler wrote:

It's an advanced editing feature.

Window->Preferences->Java->Editor->Syntax->Enable advanced highlighting

Goodness. Thanks. It works!

I take back everything I said about the feature not being there.

The feature significantly reduces my need for an additional visual
indicaton of whether variables and methods are instance, static or local.

It also improves Eclipse's syntax colouring no end.

Though - apparently inexplicably - it /still/ can't tell the difference
between a numeric constant, a type name and a package name.

Also - it seems to make Eclipse even more sluggish :-|

 

[Darryl L. Pierce]

That step is totally unnecessary if the class neme is not hird-wired into
the class all over the place.

It's not necessary to use the classname all over the place. It's only
necessary in those places where it keeps the usage from being ambiguous.

Also - as I mentioned - using the name in many places in the class
hinders readability if the class name is very long.

I disagree. Readability is in the eye of the reader.

Useful programming proverb: specify each fact in one place.

More realistic verion: specify each fact in as few places as possible.


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.

 

[Darryl L. Pierce]

Goodness. Thanks. It works!

No problem, mate.

Also - it seems to make Eclipse even more sluggish :-|

I know. That's why I mostly keep it turned off. :/

 

[Chris Uppal]

The idea of eliminating constructor names is appealing.

However, I'm not sure what syntax would be best for that.

About the only alternative I considered for "static." was "class.".

It would *have* to be an existing keyword (or a symbol?) - unless you were
prepared for name clashes with identifiers in existing code.

Well, "goto" is a reserved word, IIRC, maybe we could use that ;-)

Actually, I'd be quite happy to break existing code that used "thisClass"; it's
unlikely to be in use as a method name, and shouldn't be in use as a class name
or name of a public field, and all other uses -- if any -- are easy to change.

I also think that "this." should be available to refer to static
data within static methods - and that there should be a corresponding
static object associated with the class that is accessible to the
programmer - i.e. that Java should behave more like Smalltalk,
with everything being an object - and having a "this" reference.

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.

I would like to eliminate all that bloody redundancy, though.

-- chris

 

[Chris Uppal]

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.

-- chris