adopting oop features`round#1

5.16: adda/oop/integrating popular oop features:

. for each oop feature,
adda has to show how it's done,
or explain why it shouldn't be done
(eg, insecure, ill-fitting, ...);
eg, for oop's version of f(x), x`f,
how is adda providing f with access to x ?

where various oop styles differ:
. popular oop assumes the use of references:
all obj's are a ptr to a disposable heap obj;
whereas, adda assumes direct access to value,
ie, there's nothing to explicitely dispose of;
and when an assignment is made,
it happens to the value not a pointer .
. no garbage is generated because
any function that returns an object
does so through an inout parameter
in which it receives from the caller
the memory where the result will go .
. there are 4 modules used by oop:
a type-mgt or class object
and an instance object,
each with a {const, var} section; [6.28:
anything known to be constant is sharable;
it can be part of subprogram's code template
instead of the subprogram activation record .]

. functions of the form y = obj`f(x)
are actually calling a procedure:
f(input x,
inout obj,
inout y) )
thereby giving the function 2 implicit parameters,
represented in the method as the var's: y, and o:
# y,
as in y = f(x);
. y represents the address where
the return is being placed by f's caller .
. the function then gets to reuse y's mem .
# o,
as in o`f(x);
o is an object whose type defines f,
and f has access to all of o's internals .

adda's class vars:
. the type's body is where methods are defined;
this space can also declare variables
which are then sharable by all methods,
addressed in the usual unix way:
../local . [5.31:
. these var's are initialized at program startup,
like those in an ada package body .]

where is a local function's return directed?:

[6.1: intro:
. oop's y = x`f means f can both modify x,
and return things to y .
. a local function here means
local to an aggregate (an agg'owned function)
where (y= x.f) or (y= x#f)
can modify components of x, including itself,
and then return something to y .]
. the local function's return
can be assumed to target y because
if it wanted to operate on its owner,
it would simply use ../ to access those parts; [5.16: 5.17:
b`= obj.f -- here, obj is an aggregate;
and, one of its components is named f,
which is a function with an implicit arg of
potentially all of obj's other components;
f is in control of what gets assigned to (b);
because f determines what (obj.f) eval's to;
ie, obj itself is not what (b) is being assigned;
obj is merely the source of the function
which then provides the assignment's content .]
. the same reasoning applies to the usual
type-owned functions, y`= x`f,
they have the option of returning either the object
or something entirely different;
eg, x`++ -- this increments x,
but then returns x's former value .]
. the x`f form simply means that f has
inout access to x .[6.1:
(in the context of inheritance,
f is a abstract function whose method is determined by
the type that x belongs to,
but this feature is not specific to the x`f form,
it also applies to f(x)
-- it even applies to a+b because
both {a, b} share a common supertype
that knows how to mix its subtypes) .]

5.18: composite messages:

. obj'c allows for the composition of message-sends;
eg, x`= [a g b]; [x f y]
can be composed as [[a g b] f y]
because sending a msg to an obj typically results in
an obj pointer being returned;
ie, [x g b] points at x;
so, how does adda do that?

x`g(b)`f(y) could work the same as obj'c's
[[x g b] f y] . [5.31:
. why wouldn't the parse be
x`( g(b)`f(y) ) instead of
( x`g(b) )`f(y) ?
can the (f) in (x`f) be a variable instead a literal ?
(f x) can be expressed as (v`=x; f@v);
likewise, (x`f) could be (@x`@v) ?

. the purpose of (x`f) was to emulate
c's x++, and oop's x.f;
in those cases only literals are needed,
but obj'c has a call for variable msg's too .
. a neater way than x`@v
would be simply x`v,
where v had been declared to be a pointer to symbol .
. or use explicit parentheses:
(expression returns pointer to obj)`(
expression returns pointer to method symbol) .
. while features should be complete
to the point of orthogonal,
this should not be at expense of
unintuitive syntax;
esp'ly for features that are used infrequently .]