hybrid of efficiency and encapsulation for oop

4.8: adda/oop/hybrid of efficiency and encapsulation:

. oop's inheritance is notorious for
sharing instance var's (ivar's);
but, why can't direct access still be
more controlled, like ada param's are ?

4.10: review:
. in typical (popular) oop`inheritance,
efficiency is gained when the interface
commits to a particular list of ivar's;
the inheritor's ivar's get tacked on to
the ivar record being inherited (super's) .
. encapsulation can be maintained anyway
despite the lack of privacy,
because the super can opt to mandate
that only the super's methods
can operate on the super's ivar's .
. if opting instead to share ivar's with inheritors,
then their accesses can be done quickly
since they bypass calling a function;
but, everyone in the inheritance chain
is communicating via shared var's;
and in this way, new bugs can be caused whenever
any party of the inheritance chain gets modified .
4.10:
. one way to allow direct but controlled access
is by having optional watch functions:
. inheritors have direct access
but it's confined to reads and writes;
ie, rather than having continuous access,
it's like the ada`parameter model
where the inout param's are modeled by
copying the initial value,
working on one's own copy,
and then overwriting the param`target
when the function is returning .
. if the super wants more control over
its own ivar's,
it can put a watch on them:
after a write, it can do range testing
or check for internal consistency;
if it raises an error,
the system can know who did that last write .

. the interface shouldn't have to list ivar's;
the ivar's that are listed are simply
those meant for sharing with inheritors .
. the ivar's that actually model object state
are known only to the init functions .