[Grace-core] Visibility of variables and constants in Objects

[Michael Homer]

On Wed, Jul 3, 2013 at 6:25 PM, Andrew P. Black <black at cs.pdx.edu> wrote:
> Folks,
>
> I've been thinking more about the discussion that we (James, Andrew, Michael
> and Kim) had yesterday (at ECOOP) about visibility of defs and vars in
> objects.
>
> I'm sympathetic to the theoretical principle  that annotations should only
> restrict otherwise legal programs, and not make otherwise incorrect programs
> work.  However, I also believe in encapsulation as one of the core values of
> OOP.   Making defs and vars in objects public, just so that we can use
> annotations to restrict access to them, seems to fly in the face of
> encapsulation.  We have said many times that programs that "do the right
> thing" should be shorter than programs that don't.  Most of the time, access
> to variables and constants defined in an object should be restricted to the
> methods in that object.   So this should be the default.
"Shorter" and "entirely unmarked" are not at all the same thing and
shouldn't be conflated like this. Teaching people to ignore
encapsulation doesn't help them at all - not to understand
encapsulation, not to write better programs, and not to learn good
practices for moving on to other languages. This argument might be
correct if applied to an industrial language - Java's default should
almost certainly be private, for example - but it is absolutely wrong
when applied to a pedagogical language. Out of sight, out of mind, as
it were.

It is true that "confidential" is quite long and difficult to spell,
which you can fix by making it a shorter and more common term (perhaps
"private"), and leaving aside the insistent terminology this once.

I think fields should be actually public by default for the sake of
examples, for "records", and because otherwise you're just introducing
exactly those incantations you railed so much against right at the
start.

Examples and sample code shouldn't be triple the length they need to
be to satisfy someone's hair shirt desire. When your field definitions
need word wrapping to fit on a slide you have a problem.

"Records" - meaning small constant objects used to represent multiple
returns or the like - will be unwieldy and unused if every field has
to be annotated with something longer than the field itself. There
does need to be some simple way of performing multiple returns, and
simple record objects have many other uses.

Fields absolutely should not be lexically bound, and they even less
should be always lexically bound except for sometimes.

I agree that it would be useful to be able to annotate an object or
class definition to apply a default visibility to everything inside
it. To that extent, whether the default is public or what is currently
called confidential isn't that important. I still think it should be
public for the same reasons I gave above.

There is an interesting problem of scale - in some sense, larger
programs should probably be less public than smaller ones, but I think
that militates towards public-by-default because the extra annotations
are proportionally less in a larger program.

Alternatively the rule could depend on how many lines there are.
> I don't have a problem with the default for methods being public.  That's
> the reason to have a method: so that clients can request it.
It is inconsistent to have some methods default to public and others
to confidential, which you agreed with last time it was discussed, and
made them all default to public. You have now changed the
specification to make them inconsistent. That might well be better,
but there are competing interests there and they should at least be
balanced out carefully against each other.
> I also like to think of the "publiclyReadable" annotation (or whatever we
> call it) as generating a method.  I know that there is an alternative view
> in which variable access itself can be dynamically bound, an in Self and in
> Java.  But I think that the "generated method" view is easier to explain to
> novices and easier to understand.  The rules for method lookup are then
> simple and uniform.   Maybe the objection to annotations liberalizing
> programs could be overcome by replacing this particular annotation by a new
> keyword, such as field or feature.  Maybe "is method" is better than "is
> publiclyReadable"
A separate keyword for object-scoped temporary variables ("temp"?)
would be better than any of the other options so far if it's really
required.
> I don't yet understand why making variable and constant access lexical makes
> the name resolution rules any more complicated than they would be without
> such lexical access.  We already have lexical access to parameters and
> temporaries, both in the current scope and in lexically enclosing scopes.
> We therefore already need rules that disambiguate between requests of
> methods and access to defs.  Why is the access to x in the example below any
> more complicated than the access to p?
Access to the same thing follows two different rules depending on how
you annotated it.

To sum up philosophically:
Fields belong to objects so they should be dynamically bound. This is
essentially the same reason that lexical methods don't make sense.
It's just what an object is.
-Michael