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

[Chris Pressey <cpressey@...>]

On 18 Jan 2005 15:29:38 +1100
skaller <skaller@users.sourceforge.net> wrote:

> 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. [...]
> 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 have only the vaguest ideas of what those parts might look like, and
what they do look like in my mind doesn't exactly make me happy, so I
hesitate to describe them at the moment...  :)

> > 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.

If encapsulation was the key idea of OO, we could just say OO =
encapsulation and so many long threads that I've seen on other mailing
lists about "what is OO?" could just be put to rest... unfortunately it
never seems that simple.

The thing I'm getting from _this_ thread is that optimal encapsulation
(all state private, inaccessible even to subclasses) means suboptimal
inheritance, while optimal inhertance means suboptimal encapsulation
(the superclass has to expose all of its state to subclasses).

And since most peoples' idea of OO seems to have both encapsulation and
inheritance in it, well, it looks like there's an inevitable tradeoff.

If I didn't want any inheritance in my current project, I'd be happy
with closure-based objects with locals fors private state.  But that's
not very forward-looking.  Future programmers might have very original
ideas for how to extend these classes I'm designing that I haven't even
considered, so I probably shouldn't make them unduly difficult to
extend.  Or at least, so the theory goes.

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

But it may be possible to get this assurance without using traditional
encapsulation.  As I mentioned, a linter-type program could tell you who
is doing what to whom instead.

-Chris