"static" prefix - to parallel "this" prefix

Discussion in 'Java' started by Tim Tyler, Dec 5, 2004.

  1. Tim Tyler

    Tim Tyler Guest

    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?
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 5, 2004
    #1
    1. Advertising

  2. Tim Tyler

    Chris Smith Guest

    Tim Tyler <> 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
     
    Chris Smith, Dec 5, 2004
    #2
    1. Advertising

  3. Tim Tyler

    Tim Tyler Guest

    Chris Smith <> 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/ Remove lock to reply.
     
    Tim Tyler, Dec 5, 2004
    #3
  4. Tim Tyler wrote:
    > 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.

    --
    Daniel Sjöblom
    Remove _NOSPAM to reply by mail
     
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Dec 5, 2004
    #4
  5. 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 <>
    Visit my webpage: <http://mcpierce.multiply.com>
    "By doubting we come to inquiry, through inquiry truth."
    - Peter Abelard
     
    Darryl L. Pierce, Dec 5, 2004
    #5
  6. Tim Tyler

    Tim Tyler Guest

    Darryl L. Pierce <> 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/ Remove lock to reply.
     
    Tim Tyler, Dec 6, 2004
    #6
  7. Tim Tyler

    Chris Uppal Guest

    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.

    -- chris
     
    Chris Uppal, Dec 6, 2004
    #7
  8. Tim Tyler

    Tim Tyler Guest

    Daniel Sj?blom <_nospam> wrote or quoted:
    > Tim Tyler wrote:


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


    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?
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 6, 2004
    #8
  9. Tim Tyler

    Tim Tyler Guest

    Chris Uppal <-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/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.
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 6, 2004
    #9
  10. Tim Tyler

    Oscar kind Guest

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


    --
    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
     
    Oscar kind, Dec 6, 2004
    #10
  11. Tim Tyler

    Tim Tyler Guest

    Oscar kind <> wrote or quoted:
    > Tim Tyler <> wrote:


    > > 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.
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 6, 2004
    #11
  12. Tim Tyler wrote:
    > 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?

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


    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 <>
    Visit my webpage: <http://mcpierce.multiply.com>
    "By doubting we come to inquiry, through inquiry truth."
    - Peter Abelard
     
    Darryl L. Pierce, Dec 6, 2004
    #12
  13. 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.


    It's an advanced editing feature.

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

    --
    Darryl L. Pierce <>
    Visit my webpage: <http://mcpierce.multiply.com>
    "By doubting we come to inquiry, through inquiry truth."
    - Peter Abelard
     
    Darryl L. Pierce, Dec 6, 2004
    #13
  14. Tim Tyler

    Tim Tyler Guest

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


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


    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.
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 7, 2004
    #14
  15. Tim Tyler

    Tim Tyler Guest

    Tim Tyler <> wrote or quoted:
    > Chris Uppal <-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/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.
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 7, 2004
    #15
  16. Tim Tyler

    Tim Tyler Guest

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

    >
    > 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 :-|
    --
    __________
    |im |yler http://timtyler.org/ Remove lock to reply.
     
    Tim Tyler, Dec 7, 2004
    #16
  17. Tim Tyler wrote:
    >>>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.

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

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


    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 <>
    Visit my webpage: <http://mcpierce.multiply.com>
    "By doubting we come to inquiry, through inquiry truth."
    - Peter Abelard
     
    Darryl L. Pierce, Dec 7, 2004
    #17
  18. Tim Tyler wrote:
    >>>The feature is not present there.

    >>
    >>It's an advanced editing feature.
    >>
    >>Window->Preferences->Java->Editor->Syntax->Enable advanced highlighting

    >
    > Goodness. Thanks. It works!


    No problem, mate. :)

    <snip>

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


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

    --
    Darryl L. Pierce <>
    Visit my webpage: <http://mcpierce.multiply.com>
    "By doubting we come to inquiry, through inquiry truth."
    - Peter Abelard
     
    Darryl L. Pierce, Dec 7, 2004
    #18
  19. Tim Tyler

    Chris Uppal Guest

    Tim Tyler wrote:

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


    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, Dec 8, 2004
    #19
  20. Tim Tyler

    Chris Uppal Guest

    Darryl L. Pierce 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.

    -- chris
     
    Chris Uppal, Dec 8, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Natan

    Static vs. non-static connection

    Natan, May 24, 2004, in forum: ASP .Net
    Replies:
    8
    Views:
    7,353
    Sami Vaaraniemi
    May 26, 2004
  2. Chris  Chiasson
    Replies:
    6
    Views:
    635
    Richard Tobin
    Nov 14, 2006
  3. Soren
    Replies:
    4
    Views:
    1,305
    c d saunter
    Feb 14, 2008
  4. Vivek Menon
    Replies:
    5
    Views:
    3,432
    Paul Uiterlinden
    Jun 8, 2011
  5. Vivek Menon
    Replies:
    0
    Views:
    1,788
    Vivek Menon
    Jun 10, 2011
Loading...

Share This Page