[E-Lang] get, set, and dot

Dan Bornstein danfuzz@milk.com
Mon, 26 Feb 2001 14:49:18 -0800 (PST)


Karp, Alan writes:
>I don't like the dot notation because it hides a semantically useful
>concept.  There is a real difference between foo.blah=1 for a public
>variable and foo.setblah(1) with a public method.

Agreed, sort of, but...

>Actually, I'm opposed to the use of public variables.  All variables should
>be private and accessed with getters and setters.

...once you've gotten rid of the "dangerous" form of public variables, I'm
in favor of providing the standard syntactic sugar for the method-access
form.

My take on it is that the reason people define public instance variables in
Java is because of the convenient notation to access them, not because of
some high-falootin' ideal of how it's implemented, and it would be in
keeping with the spirit of E to provide a cleaner and safer version of the
same familiar and convenient syntax.

>I don't find the extra typing to be a burden

Note that there is "extra typing" for both definition and access, and in
this case, I *do* mind it. However, because I'm a "safety first" weenie, I
end up cursing Java every time I end up writing a private variable plus
accessor methods.

The things I object to in Java about public instance variables are:

    * Get and set access cannot be separated. That is, you can't have a
      non-final variable that is only privately writable[*].

    * You can't "change your mind" and transform a simple variable into a
      method access without disrupting your clients, forcing them to
      rewrite their usage of your class.

If these problems went away, in one way or another, I'd stop my
complaining.

There is certainly a matter of properly setting the expectations of users
of the dot notation (e.g., "foo.blah" is *supposed* to be a simple
variable-like access), but I think the right way to do that is with
documentation, not technical restrictions in the language itself. Note that
there is an analogous problem in the purely-method space in Java, already.
For example, if you saw a method with the signature "Frobiness
getFrobFactor()" your expectations are that it will act kinda like a
variable access. The expectation should be just the same for
"foo.frobFactor".

-dan

[*] Actually, this is one area where Java the VM and Java the language
    differ. Per the VM spec, final public variables may be set by any
    method of the class they are defined in, and as many times as you feel
    like it; but per the language spec, final public variables may only be
    set in constructors, and only ever once per instance.