semi-type-specific subheaps

14: adda/oop/type-specific heaps:
[29: intro:
. in a type-specific heap,
each object reference has 2 parts:
# an ID of the type it belongs to,
# a serial number unique to that type . 31:
. this promotes encapsulation,
because the reference isn't a pointer,
the only one who knows the object's address
is the type mgt that owns the object .
]
. given the idea of type-specific heaps,
how does that mix with adda's oop?
--that's the efficient form of oop;
the inefficient way of doing oop
uses garbage collection
and that is a choice independent of
which heap an object is owned by,
whether local or global .
. using pointers is not what causes
pointer semantics and garbage:
that's caused when assignments are overwriting
the pointer instead of the pointer's target:
to avoid garbage collection,
assignments need to overwrite the objects themselves
not the pointers to the objects .
. instead of a global type-specific heap
local vars would be placed into
the subprogram's local heap
that can have within it type-specific subheaps .

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 .