Re: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core

[skaller <skaller@...>]

On Tue, 2005-01-18 at 13:47, Chris Pressey wrote:

> > > But how would you refer to a superclass's private instance
> > > variables?  'x' in your example is sort of a special case, since
> > > it's passed in the constructor.  What if base() defined a local y
> > > for its own use, and you wanted to get at that?
> > 
> > This is harder to do, although probably possible.
> 
> Possibly.  But I've yet to think of or read of a way that doesn't use
> the debug interface.

That wouldn't be acceptable, to me at least. The requirement
would be to use core technology -- closures, coroutines, etc,
to emulate the features of OO.

To do that, it may -- well, certainly will -- be necessary
to follow some protocol which means a use will be styalized
Lua code. It will not look exactly like a core supported class
system, but the idea is you *could* write a translator for
some native OO syntax and treat it as sugar generating
plain Lua.

Using the debug interface would be 'cheating' because the idea
is to show that with basic language features like closures,
you can emulate OO style in a simple way.

If this is not possible -- and the operative word here is 'simple',
then it is a good argument to examine the Lua core, find out
what is missing, and add it. Not necessarily the whole of an 
OO system, but the part that is needed to provide a simple
emulation.

I am primarily concerned with semantics, not syntax -- adding
syntactic support for OO features which can be emulated is 
really another issue. Lua already has such syntactic sugar,
and a bit more is unlikely to be a problem provided is 
demonstrably useful -- this is quite different to
interfering in the core system to add features, which 
would threaten the minimalism. An extension to the core
really needs very strong evidence it is essential to provide
a vital feature.

> > No, that sucks. That isn't a solution.
> 
> I'm not sure anymore.  Outside code that is determined to abuse my class
> can do it anyway, so I'm mainly concerned with preventing accidental
> misuse of my state.  

Yes, but modifying what should be a private
variable is easy to do accidentally.

> 
> This all suggests to me that the idea that Lua's "just please don't
> touch" policy really is a reasonable solution.  

I don't think so. The key idea in OO is encapsulation, which means
being certain no one can fiddle the internal representation of
some type and break vital invariants.

Without this assurance, your ability to reason about your code
in terms of the interfaces of types is lost.

One technique, used in Python, is to name the private things
starting with "_". This was so common, the interpreter was modified
to enforce it. Note there are still ways to get around the
enforcement (using dictionaries) but such tricks are
fairly visible.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net