oop theories, designs, implementation notes

6.1: adda/oop/based on vari-sized records:

. the 3 sorts of inheritance:
# subtyping:
. inheritors are assignment compatible .
# symbolic description:
. describes one type in terms of
another (incompatible) type .
# generics:
. an object's function is selected by
the function's name (or hash of that)
-- rather than referring to methods by
index, pointer, or offset .
-- this is the obj'c meaning of inheritance; [6.7:
obj'c also supports subtyping . 6.30:
... actually,
any system that supports generics,
implicitely supports subtyping .]
. after review oop ideas,
I wondered if the the trailer idea
would be useful for oop subclassing .

. parameters that vary in size
are accommodated by replacing value with
a mini-pointer (an index into
an associated trailer array)
that then leads to the value .
. a vari-sized record is organized as
a head (the mini-pointers)
and body (the trailer).
. in the vari-length record,
the number of fields is fixed,
whereas in multi-inheriting oop,
not only does the body grow
but the head too is vari-sized .
. provide a mini-filesystem (fs)...
[6.30:
. each class expects to find
it's own instance variables
arranged in the usual way
even when it's one of many ancestors
of the obj's class .
. in a mini-fs, the directory
doesn't have to be on the obj;
just containing a type.tag,
will be eno', since that is a
key to using the lib mgr's map:
(instance's class, ancestor.class) ->
offset into instance .
-- this map shows what offset to use
into the instance
to get to an inherited class's
embedded instance record .]

6.30: todo.adda/oop/obj'c dynamic linking:
. when there is multi-inheritance,
you have an instance variable where
there are separate sections
for each subclass's privates .
. it would be efficient if type-mgr is
passed ptr's to the operated obj's;
and generally,
how is each type-mgr supervised
so as to insure that they
don't affect any surrounding bits?
. you trust your compiler,
but then in obj'c,
you can relink modules dynamically;
and, the new module might be
code from another compiler .
. need to review obj'c
for how to best use,
and not be used by, that subsystem .

6.5: adda/oop/how does c do obj'c dynamic bindings:
. the generic-oop functionality of obj'c
comes from being able to launch a subrogram
when given a function`name and a type.tag;
this could be done in unix by calling to the os
to execute a shell command;
. without that ability,
each addition to the class library
would require editing the obj'c run-time engine
and re-linking it with the expanded class library .

6.7: adda/oop/subclasses as subtypes:
. what is a new type, vs a subtype, in adda?
subtypes can't remove or ignore
inherited functions,
but new types can do a reuse but remove;
how does Ada do this ?
inheritors are new types (meaning it's
not assignment-compatible
with the inherited type);
if you want a variable to have subtype polymorphism
(ie, be assignment-compatible with
all inheritors of Baseclass),
then you need to declare the var's type to be
Baseclass'class .

6.23: pos.adda/obj'c and cocoa bindings:
. the reason to not interface cocoa
is that it's very inefficient with its
ref'counting and its (typical) way
of implementing oop .
. to the extent there does need to be
a binding to it (for the sake of
getting the usual services)
the binding will not be direct:
the mac gives all the power to the developer,
whereas addx will give the user
most of the gui design .
. for example, in nu,
"( locally-scoped assignments are
instances of NSMutableDictionary; )
this might look like an
excellent chance to reuse,
but you might be using thousands of those,
which means juggling a lot of within
both your subsystem's heap
and the mac's system heap .
. it might be ok for prototyping,
but eventually, you want basic services
to be based on your own mem'mgt .