[288] in java-interest
private methods (again); class evolution
daemon@ATHENA.MIT.EDU (Eduardo Pelegri-Llopart)
Mon Jun 12 17:37:57 1995
Date: Mon, 12 Jun 1995 14:23:33 -0700
From: pelegri@calterra.Eng.Sun.COM (Eduardo Pelegri-Llopart)
To: java-interest@java.Eng.Sun.COM
I want to reopening the topic. I would like to propose \changing/ the
semantics of private (& protected) methods so they affect visibility,
not just accesability.
The only advantage to the current semantics is that it disallows the
situation where a class implementor changes a private method from
private to public and clients of that class misbehave when resolution
suddently varies, or fail to compile when a method invocation becomes
ambiguous.
Arguments against the current semantics include:
* Say the implementor of a class wants to change its internals. Today,
it can either extend an existing method, or add a new private method
and risk making some client of the class invalid because it might make
some call ambiguous. An alternative is to add a private variable to
the class, add the new functionality to that class and pass the
private data around.
All of these solutions seem awkward to me. Adding an invisible
(private) methods seems the right thing.
* "Promoting" some method from private to public does not seem to me
to be a particularly distinguished special case of the creation of a
new public method. Adding a new public method can lead to the same
problem of invalidating client code, or making a resolution change.
Actually the only reason I can think why this change is special is
that, in C++, the object layout does not change, and this might be
used to remove some work in some compilation systems; but this does
not apply to Java, where the object layout is not important.
* Changing private to mean visibility should not invalidate any
existing code, so it is relatively easy to do.
* Finally, in Design and Evolution of C++, page 55, Bjarne Stroustrup says
about this issue:
"Why did I define it that way, and was it the right choice? My
recollection on this poit is vague and the stored records are of no use.
One point I do remember from the discussion at the time is <the argument
above> ... I no longer consider this argument conclusive (if I ever did),
but the decision has proven useful in that it allows programmers to add
and remove public and private specifications during debugging without
quitely changing the meaning of programs. I do wonder if this aspect of
the C++ definition is the result of a genuine design decision. It could
simply be the default outcome of the preprocessor technology used to
implemented C with Classes that didn't get reviewed when C++ was implemented
with more appropriate compiler technology".
In the same topic, it would be nice if the java compilation system
checked that using a newer version of a class definition is not
changing the resolution of some call in a way different to what it did
with the previous version. This requires extra work, but it would be,
IMO, a step towards a real solution to class evolution.
Rebuttals, clarifications, etc, most welcome.
- eduardo
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
