"static" prefix - to parallel "this" prefix
 

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

http://checkstyle.sourceforge.net/co...ml#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?
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Re: "static" prefix - to parallel "this" prefix
 

Tim Tyler <tim@tt1lock.org> wrote:
> 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

Re: "static" prefix - to parallel "this" prefix
 

Chris Smith <cdsmith@twu.net> wrote or quoted:

> 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.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Re: "static" prefix - to parallel "this" prefix
 

Tim Tyler wrote:
> http://checkstyle.sourceforge.net/co...ml#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.

--
Daniel Sjöblom
Remove _NOSPAM to reply by mail

Re: "static" prefix - to parallel "this" prefix
 

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

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

Re: "static" prefix - to parallel "this" prefix
 

Darryl L. Pierce <mcpierce@gmail.com> wrote or quoted:
> Tim Tyler wrote:

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

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.

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

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.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Re: "static" prefix - to parallel "this" prefix
 

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

(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

Re: "static" prefix - to parallel "this" prefix
 

Daniel Sj?blom <dsjoblom@mbnet.fi_nospam> wrote or quoted:
> Tim Tyler wrote:

> > http://checkstyle.sourceforge.net/co...ml#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.

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/download...1-M1-News.html
http://download.eclipse.org/download...e-news-M2.html

....or...

http://download.eclipse.org/download...-part1-M3.html

What version of Eclipse are you using?
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Re: "static" prefix - to parallel "this" prefix
 

Chris Uppal <chris.uppal@metagnostic.remove-this.org> wrote or quoted:
> 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/...eda7465055571c
>
> (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.
--
__________
|im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply.

Re: "static" prefix - to parallel "this" prefix
 

Tim Tyler <tim@tt1lock.org> wrote:
> I've been playing with the Checkstyle "Require this" check.
>
> http://checkstyle.sourceforge.net/co...ml#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.


--
Oscar Kind http://home.hccnet.nl/okind/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2