On Fri, 11 Apr 2003, Stephane Ducasse wrote:

> > On Friday, April 11, 2003, at 12:01  PM, Swan, Dean wrote:
> > On a more practical point, the idea of using self-like messages to
> > define instance variables would be acceptable IFF those messages were
> > properly private. In order to provide this privacy one would need to
> > implement some mechanism to allow properly private methods and the
> > same mechanism would (very likely) solve the worries about overly
> > public methods already in the system. I'd be quite happy to see such a
> > privacy mechanism if anyone has good ideas.
> Nathanael is playing with a really nice model to introduce a kind of
> 'open'
> privacy mechanism based on explicit interfaces that a class could
> present to clients
> (not a java like interface). Once this will be ready for feedback we
> will certainly let people play with it and we will have some papers
> about that.

The privacy mechanism that I'm considering for Slate is that one could
define a package to have a privacy scope itself. Basically there would be
distinctions between public and private methods, including accessors,
which affects whether the sender can access the operation based on what
package includes the sender. Of course packages can extend priveleges to
other packages (to allow named extensions, eg), but the main idea is that
code written as a unit should not have to deal with an extra barrier of
security.

This is easier to handle for languages which don't allow dynamic
inheritance, of course, because the scoping can be checked at
compile-time, even if you subclass into a different package. This is in
fact one of the many reasons we may include a static inheritance mechanism
in Slate, but it's too early to say what the resulting design would be.

> My original question was related to that but I did not want to explain
> the complete picture. The idea of removing direct access is a
> discussion we got internally for at least two years and I simply wanted
> to see other opinion that ours. That's why I would like to understand
> the point made that the Brian (the Slate guy) and Jecel as it seems
> that they got a lot of experience with that.

The only other note I could could add is that direct-variable access when
we have this method of providing different accessors would be a reflective
access. This gives a clear distinction between normal and "fiddling"
levels of activity, so again to make it easier to analyze.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water at tunes.org
http://tunes.org/~water/