[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: RES: RES: RES: idea of vision of blueprint of ROADMAP of Lua core
- From: Klaus Ripke <paul-lua@...>
- Date: Mon, 17 Jan 2005 15:22:39 +0100
On Monday 17 January 2005 04:10, Chris Pressey wrote:
> But how would you refer to a superclass's private instance variables?
you meant what is usually called "protected"?
> What if base() defined a local y for its own use, and you
> wanted to get at that?
well, you don't
> But subclasses of K sometimes need to mess with K's state directly in
> order to extend K in some way.
if there's messing around from the outside, the state is not private
> any OO language has to deal with this dilemma somehow.
``Real´´ OO languages do not have any concept of protected,
it's just a workaround as broken as e.g. C++ multiple inheritance.
It's like "which part of ``private´´ didn't you understand"?
A subclass is just a client like anything else, and there's
perfectly no reason why it should have special privileges.
Often enough I saw people subclassing something just to get access
to it's ``protected´´ state, which is ridiculous and self-defeating
(not to mention "final subclasses" as proposed antidote).
It really only works if you confine everything to some ``package´´
(in the Java sense) in the first place, but then you don't need protected.
To control the extend of what is ``protected´´, you must not allow
any other code to step in short of boarding your package.
So protecting an environment IMHO essentially boils down to
have modules of a ``package´´ share parts of the same closure.