oop (obj'oriented programming)

8.16: adda/oop/avoiding unnecessary polymorphism:
. when is polymorphism required?
. type polymorphism is that aspect of oop
which is most essential to simplifying a system .
. it comes at the cost of data using additional memory
in order to specify a type.tag,
which can be used at run time,
to determine which routines can actually handle
the type an obj' has at the time of the call .
. when can adda replace an arithmetic expressions
directly with c native types ?
it has to know at compile time what the input type is .
. the important feature of the translation system
is that it lets you specify type info if you want to;
and, program efficiently as in c;
but then, it also makes sure
that you follow all the rules
that are needed to safely use c's numeric types .
. initial versions of adda may want to simplify things a bit
by just converting all code to the oop version of numerics .

8.28: adda/oop/private vs public:

. is there some slicker way than explicit tags
to indicate whether a package symbol is {public, private} ?

. start with the idea of 1st-class functions:
sub's are declared like local var's .
. publics are declared in the body of a datatype or type.class .
. locals of types are found in the bodies of their operations,
or in their instances (instance var's)
or in the locals of type'mgt (class var's),
ie the body of the type's def' .

. how is the type'mgt process defined?
t.type`= [/]value; where in this case,
[/]value is interface .
then t`body`= value; where the value of the body
is a list of def's for symbols found in the interface .
. just as every type needs to define or inherit
the instance's {ini, fini} handlers, (12.19:
for the instance var's)
it also needs to define a sys`{ini, fini} (12.19:
for the class var's in the body of the type's def') .
. the var"(sys) is a process rather than a procedure,
so it is retaining the activation created by sys`ini
until the run-time system calls sys`fini .
. this activation record contains locals
that can be shared among all type`instances`operations
by referring to sys`/somelocal/ .

8.29: revisited:

. rather than have the public symbol"(sys)
being the activation record for the type`mgt,
the design should be more like that of ada's package .
. think about 1st-class functions,
and how a var' of type"(function) has as part of its
type description -- indep' of its value --
the type's of its param's and expected externals;
eg, f(x.t).rtype .
. this type description can be thought of
as similar to the head of an ada`package .
. likewise, the function's value
-- it's algorithm and activation.record`declaration --
is similar to the body of an ada`package .
. in both cases, you implement body by refering to just that:
eg, f`body`= (.(x) code for expressing f(x) ) .

. ada's way is for a package to be initialized once
upon activation of any client;
this apparently works like multiple readers opening a file:
. reader activation does an open,
then the system checks for it being open,
and does so only if needed .

. in the analogy with functions,
notice that the parameter symbols are expected to
match those in the body of the function
(the assigned algorithm) .
. likewise, symbols in the head of a type's def'
are visible in the body of the type's def'
-- and are expected to be defined in the type`body
just as parameters with defaults are defined in the function`body .

. the type's body is like an extension of the type's face;
except the body's symbol's are not visible to the face .
. the body and the face together are like a {record, struct}
whose fields can include functions;
again however,
while it's possible to use record notation to
qualify a type's functions: eg, number`+(...);
it is not possible to access record fields
without qualifying them with record notation .

. when defining the bodies of face's functions separately from the type`face,
it's assumed that bodies have access to
locals within the body of the type'mgt .
. this will seem natural if the function's bodies are
defined within the type'mgt's body,
as they will obviously be within the same scope;
but the same is also true if a function's body is defined separate
from both the type`face and type`body .
. this is simply being consistent with
the way things are for nested subprograms .
. when things are separate,
all expected externals must be part of the param'declaration;
otherwise, it's assumed that the separation is perfectly modular .

8.29: sci.adda/oop/inheritance:

. is there an elegant, intuitive design for inheritance?
. there are several dimensions:
. there are several use-cases for inheritance:
reuse of implementations,
reuse of interfaces as in type-clustering,
and reuse of interface as in assignment compatability,
or familial class affiliation .
. the entire lifetime of components must be considered:
. how can subclasses update themselves in a way
that is not going to break things .

. when type compatability is the goal,
then, as in ada, there is a typedef for that:
t.type`= is and(t1, t2, ...) .
. for those that are trying to simplify design
by describing one type in terms of another,
but don't want compatability,
t.type`= ( include t1 - --[minus this list of symbols]
, include t2`body -
, ... )
--. this example shows inclusion options:
including t2`body implies inclusion of the head,
whereas, inclusion without specifying the body
refers to just the head .
. another option is whether to do include's dynamically;
or to mean that the current definition should always be used,
regardless of whether that definition changes .
. in the static version, inheritors would be notified
that previous building blocks have changed .
. dynamic versions would work in a modular way,
where a type or any other module is a plug-in,
which can be replaced with another plug-in (having a different body) .
that may have an extended interface .
. now, since clients could have also have extended that interface,
accepting dynamic inheritances must mean
that any changes to the interface are seen only by future clients .
. previous clients would be asking for links only to
those symbols in the interface that they did inherit .

8.29: adda/oop/derived vs primitive:
. obj'c's definition of "(derived function)'s
are those methods defined in terms of the primitive methods;
implying that when you inherit from an abstract class,
the derived functions are already implemented for you .
. how should adda syntax indicate what are primitives ?
. ada's primitives are the ones in the head of a package .
. in hierarchical pkg's, the child packages are not primitives .
. eg, type number has only primitives,
then number/lib has derived fun's .

9.13: adda/oop/efficiency through compiler work:
. how is adda giving type.class's privacy
while also allowing selective typing
without making users talk about un|boxing?
. just let the users use type.class|cluster's,
and then if they use an obj' in a way that
conforms to the protocols of a native type,
then let the compiler make the replacement .

9.13: adda/oop/cluster and type tags:
. the type.tag can be a full int,
as it can store not only type but also size of current obj
(eg, numbers are often an array of ints
whose size is depending on the number of digits in the number),
. a negative tag could indicate special situ's,
like when there is no data besides the tag,
and the tag itself indicates a named constant, (eg, e, pi, ...) .
. the neg'tag could also help with efficiency in other situ's:
. tall types add only a few values to the type.tag:
(ptr, func, immed),
so then a neg'tag could be indicate to the decoder
that this has got a tall field to pull out,
and then the remainder of the int is the type.tag .
. dynamic typing allows an obj' to be any type.cluster
(ie, string, number, ... );
so then neg'tagging could indicate the type.tag includes
both the type.cluster and the datatype .
review of clusters:
. number is a type.cluster because it clusters
the type.classes" {R, N, Z, C, Q}
. the type.class of Z contains the datatypes:
(int8, int16,int32,int64, int-multibyte) .
. once the type.cluster.tag is known,
the datatype.tag`code can be understood,
(because it's registered with a particular type.cluster) .
. then calling datatype`type.class
will tell whether it's a {R, N, Z, C, Q} .
. user`defined type.classes can specify range limits,
and then the compiler and/or type-mgt can translate this into
what datatypes to use for it .

10.14: adda/oop/inheritance forking:
. one benefit of inheriting
is it allows a base class's code fixes
to be auto'ly applied to code of inheritors .
. a problem is when the super class wants to
change its impl' in a way that breaks the code of subclasses .
need idea of a subclasser's interface
similar to idea of clint interface
. if super changes subclasser's face
then these changes cause a fork in the inheritance
so that past inheritors can keep the code they have,
while new inheritors can build against the new face .
. this idea depends on a robust contract-expressing system .

adda/oop/needs auto'unit testing:
. any time a superclass updates,
unit testing is run by adda on the subclasses
for checking that the change doesn't break code
since even if face the same,
critical behaviousrs could have changed .
. a common misbehavior is when a server
switches employees who don't get it[the contract] .

10.14: adda/defining auto'conversions by converter visibility:
. when specifying subtypes
there are 2 options when constaints are broken:
* warn user (raise exception)
* auto'ly convert:
eg, when inches are assigned to mm
then it auto'ly does the inch2mm.conversion;
eg, when real.type is assigned to int, then do the rounding .
. conversions make sense whenever available,
whereas, if a subtype restricts the value's range,
then when values are out of bounds, an alert is required .

todo.adda/modular type.def:
. t.type`= < literals, uniops, biops >
t`literals`= {...}
[10.18: this may be too unlike vectors ...]
. how is inheriting like something else
so that they can share syntax?

. obj'composition (ooc) involves building trees a lot
since all is ptr-based .
. this reminds me that in addition to local heaps
potentially large obj's may want their own heap .
. also,
recent plans saw a need to keep globals showing current heaps
this may need to include current obj .

adda/oop/selectors and literals as symbol.pointers:
. by the recent definition of const,
the type can be inferred from the value
but this is only when the value is present at the time of declare .
eg, var.!`= init,
and it assumes every literal can be identified as
belonging to a certain type.class,
so then the var`type is
whatever the init's type is .
. the polymorphism can be seen in the example of
the file.interface
which includes responding to the open.function .
. consider the open.symbol to be a global,
so then the open.message is just a symbol pointer
rather than a method (code) pointer .
. likewise, all of the literals are global symbols,
and a type whose literals are symbols
has bit.values that are actually symbol pointers .
. for the efficient enum typing,
the type is actually describing
a function: symbol-> bit.vector .

. obj'c relates the word category to classifications
. I recall from philosophy that category had a particular meaning:
the category of quantity includes:
{ nullity, unity, infinity, 1/infinity (infinitesimal),
cardinal, ordinal, complex, ... }
. Aristotle had claimed that the following ten predicates or categories
could be asserted of anything in general:
substance, quantity, quality, relation, action, affection (passivity),
place, time (date), position, and state.
"Category`root is Greek"kategoria:
"that which can be predicated about something
(publicly declared and asserted)"
A category is an attribute, property, quality, or characteristic
that can be predicated of a thing. "
... I remark concerning the categories ...
that their logical employment consists in their use as
predicates of objects."
Kant called them "ontological predicates."
adda/oop/type vs subtype:

. from learning about obj'c oop,
I'm becoming aware of missing ideas for
how I would say all things oop in adda's lang' .

instead of type.type's that can be either new or subtypes,
let type.type imply that a new is being declared
whereas, a subtype.type implies compatability .
. mailbox is a {species, type} of container (a subtype of container) .
. num.type; int.subtype`= num .
. if int is a num, then num`= int;
if num`frac =0, then int`= num .
. num =z, r, q, n,
how to express subtypes?
ir = infinite repetitions: (e, pi, ...)
z = n u -n
q = z/n,
r = z+q u ir
c = r + r i => z
q is about having divisions be treated like const irrational symbols
since they are not exactly reresented in finite ways,
so save the dividing operations when float.types are needed .
. irrational types may be represented by functions that
give the const to a given (arbitrarily large) precision .
(and like the division, be expressed only when float.types are needed).

. any obj' expecting num's face (available operations)
can work with ints too
but compatability depends on direction of assignment;
eg, a parameter's type will differ
depending on whether it's assigned a value or an address for out.mode:
an obj's subtype is a constraint confining it to accepting only a certain subtype .
. the value must be a subtype of the address it's assigned to;
the address must be a supertype of value being assigned to it .
{super,sub}.type is an ambiguous terminology;
in obj'c and much of oop literature,
the subtype is able to respond to
many more functions than objects from it's supertype .
. that's because the subtype is constraining the inherited set of values
to those that make sense being applied to the additional functions .

the parameter may potentially need 2 types:
one for what subtype it expects from the caller,
and another subtype telling the compiler
what it expects the range to be within
while being operated on by self .

. there are several typing mechanisms to consider
and there should be integration wherever possible .
. dimensioning is a sort of datatyping
where numeric values have factors indicating
what substance they are amounts of .
. ada has something like interfaces,
but is related to dimensions in that
instead of letting numeric type mix with any other,
they have to agree in dimension also;
that means that they follow an interface but apply a constraint .
. in addition to dimension is coordinate systems
involving umbrella types of sorts
since there should be a way to convert between any coordinate systems
that are being used to measure the same dimension:
eg, length can be in inches, feet, the sum of both, or meters .

. oop is all about subtype polymorphism:
assignment compatability between various types
for various reasons .

. the sort of oop that type"number is an example of
is called nominal coercive subtyping
where various types (complex, real, integer, rational, modular)
are nominated to be different implementations of some umbrella type (number)
whose job it is to handle conversions and relegation;
eg, (int / complex) is a mix of subtypes
that needs to have one type converted
so they will both be the same subtype
to which the operation can be relegated to:
(complex/complex) -> complex .

. all other forms of oop are called inclusive rather than coercive
because instead of being able to mix subtypes within binary operations,
the interface is confined to unary or parameterless operations .

. the sort of oop exemplified by obj'c inheritance
is called nominal inclusive subtyping
because subtypes are nominated by declaring who their supertype is .

. the sort of oop exemplified by obj'c protocols
is called structural inclusive subtyping
because instead of nominating a type to be compatible with
its abstractly refering to any type that uses the same structure
(complies to the same interface or protocol,
ie, responds to the same set of messages)
. it's inclusive:
they are sharing the same interfaces
(the structure of assignment compatability) .

. the original extent of oop in Python was parametric polymorphism,
where instead of a parameter declaring itself to be of a given type,
it can be compatible with any type that can respond to the needed messages .
. this would be structural generics
in contrast to the nominal generics provided by Ada
where a parameter's type can itself be a parameter;
ie, the caller has to supply the name of the type
to which the other arguments belong .
(Ada additionally requires this be done in 2 steps:
intstantiate the generic,
and then use result with your chosen type) .


10.28: bk.engl/subtype:

If S is a subtype of T,
any term of type S can be safely used in a context where
a term of type T is expected.
. this is called subtype polymorphism
vs, parametric polymorphism, the term for generics .

(nominal subtyping)
The class-based object-oriented subtyping described above is nominal;

(structural subtyping)
a structural subtyping rule for an object-oriented language might say
that if objects of type A can handle
all of the messages that objects of type B can handle
(that is, if they define all the same methods),
then A is a subtype of B regardless of whether
either inherits from the other.

Implementations of programming languages with subtyping
fall into two general classes:

(inclusive implementations)
in which the representation of any value of type A
also represents the same value at type B if A<:B,
The subtyping induced by subclassing in oop is usually inclusive;

(coercive implementations)
in which a value of type A can be automatically converted into
one of type B.
. subtyping relations that relate integers and floating-point numbers,
which are represented differently,
are usually coercive.

adda/oop/mixing tagged vs constrained:
. complication
when some num's are not boxed (type-tagged),
there needs to be assignment to unboxed with compiler indicating type
eg, int in {int, mod}{8,32, 64, 128} .
. also need to separate adt from polymorph's,
eg, if Q is needed without translation to other subtypes of num
then no type.tag is needed while compiler
statically converts literals;
eg, x.Q`= 4(= 4/1) -> [Q be fraction](x, 4,1),

. num.supertype is < subtypes: Q, Z, N, C, R ...>
. impl' num.supertype to get idea of how to make syntax for
supertypes generally .
. notice the behavior of supertype
can be drawn from def's of its subtypes:
instead of going on tag,
see if any has value that can be reduced to a simpler subtype:
Q`frac = 0 ?
tag an N = 0.1, ... inf,
... ((ideas about how to give special operators for particular subtypes)) ...
C= real * complex.sign
C= * complex.sign
R = C sign`im = 0
Q = R- ir's

space in {continuum, discrete}{value, sign}
C= continuum.val * continuum.sign
R = continuum.val * discrete.sign
N = discrete.val
M = modular discrete.val ( max+1 = 0, 0-1 = max )

. modular is usually described as a
partitioning by equivalence classes:
. for N modulo 8, the classes are {0..7}, {8...15}, ...
0 mod 8 =
8 mod 8 ...
and this system should also make sense for reals
(that would be sub.second clock arithmetic) .
. it would work for any reals, not just floats,
it's clock arithmetic where numbers are equal if they are
the same angle on the clock dial .

adda/oop/supertypes declaring subtype:
num.supertype is
< ;;;
sub: R, Q, N, Z, C
; uni: -, /, log#{2,10,e}, sign, value, `real, `im
; bi: -, /, *^, |
; multi: *, +
. the idea at the moment about oop architecture
is that supertypes (type clusters)
are the main type and you don't need to
worry about later adding a type (subclassing)
because the theory of the type involves
being aware of all the subtypes in advance
because this is required for knowing how to handle
cases of mixed-subtype binary operations;
that is,
for this kind of type,
you couldn't add a subtype without having to
recode the mother type anyway .
. then for the other features of oop,
there would abstract interfaces (protocols)
and an implementation would have the option of
importing another implementation (cloning for subtyping) .
. this is very simple while also powerful .


[11.2: intro:

subtype.tags -- in contrast to type.tags
which identify who mgt is --
are used internally by type'mgt to distinguish between
eg, the same 4 bytes of a number may be used as
either a single integer,
or as a pair of ints that make up a fraction;
so, the subtype.tag would tell number`mgt
whether this obj was an large integer or a fraction;
the type.tag would identify the type.class;
eg, number vs character .

. type.tags are needed when a parameter has
no particular type;
rather, it's declared only as being
any type supporting a particular interface .

. oop is known to be memory-intensive
because it's based on adt's
where instead of an obj's state being determined by
a particular set of functions constituting the obj's type,
it can be defined by any number of types
so that the given state can be identified only by
knowing -- by type.tag --
what type has been designing its state .
. in its most free form, adt` obj's can be of any size,
so then it becomes common to implement an adt` obj
as a pointer into a varying-sized string of memory .
this pointer and tag.type
can easily add 2 bytes to every obj' . ]

. one way to reduce this use of memory
is by having types declare sizing variants
each of which consists of a starting size
and whether it wants the option to be growable;
eg, a typical number will fit in 4 bytes,
but depending on the number's subtype or value,
it could need many more bytes,
so then this need to grow
would be accommodated by
using some or all of the original 4 bytes
as a pointer into some heap (typically the heap would be
the trailer.space of the enclosing act'rec or container) .
. if the system manages all bit & byte-level addressing,
then a type can resize without being aware of the details
of how the growing took place;
in fact,
perhaps this is best done by the system,
where the system analyzes what sizes the type uses per value ranges,
and then declares this sizing for a type;
wondering if type developers might be able to
design more efficiently
if they knew the details of this scheme
and were partners in it .
. to support this sort of variant structure,
the system would need to add a sizing.tag
that indicated whether an obj had been extended into trailer.space .
. the sizing.tag could also indicate a variety of base sizes,
or else the base size could depend entirely on the subtype.tag
. due to there being allignment requirements on some platforms
(eg, a 4-byte integer works fastest on a 4-byte boundary)
and considering the varying size of tags,
the best way to store tags for items in structures
(arrays, records, act'rec's, etc)
is to dope-vector them out to the struct's trailer.space .
. this way the system is free to dynamically change the tag impl'
to take advantage of circumstances such as
finding that all obj's are the same type,
so then in that case,
all the type.tags could be replaced by the variant:
[this tag applies to all items] .
. likewise for sizing.tags .

. with this ability to dynamically restructure the tagging info,
the system's efficiency can come in increments .

. the array structure can change indep'ly of its components:
. the array's header contains the type for the whole array,
and if it depends on the index,
then the header will indicate it's a dope vector into the trailer,
pointing at a bit.field array that grows in size
to match that of the data.branch of the array .

. if all components need type-tags,
then the size of the type.tag depends on
the degree of variation:
eg, if system determines this array will contain only
2 types,
then the remembering the choice between these 2 types
can be mapped to a single bit .

adda/oop/static vs dynamic polymorphism:
. if oop design is looking complicated,
keep in mind the priorities:
type.clustering (subtyping, like numbers do)
and interfaces (protocols) .
. clusters provide static vs dynamic polymorphism;
it's the dynamic subclassing that is very problematic .

adda/oop/type.cluster"{string, tree}:
. suppose type"string lets string's variants include
either ascii, unicode, wordcode, or ptr to str;
in that case:
string insertion can be speeded up by tree operations .
. new subtypes can be joining the string.type
by following the interface
which includes being able to report self`size
and whether all char's are fixed size (vs varying like unicode) .
. array's (a generalization of string)
could work like this too;
or instead,
refer to the above style of str's as being char.tree.types
rather than char.string.types .
. tree structuring really helps when instance`sizes are sure to
vary within a subclass.

adda/oop/obj`size but no simple type`size:
. sizeof with polymorph's?
it can be complicated getting the size,
there is also an arrayable version
that is with a fixed-sized head, and a vari-sized trailer .
. if it's any use, there is always current size per obj',
and per container,
but not the type`size that c users are accustomed to;
then again, they won't need the size to find
the needed mem'size to alloc .
] .

todo.adda/oop/need to back up terminology: [done]
. diff'ing supertype vs superclass:
( supertype is coercion mgt;
so, there's just one root type
superclass can inherit from a non-root class
. also diff subclass vs [11.6: subframing:]
reuse of body along with face

adda/oop/structural compatability:
. to support structural compatability
as expected intuitively,
(eg if 2 arrays have the same component type,
they should be able to share slices),
the previous syntax for subtype may [need to] assume
compatables must be nominal var
can be any type until typed by dimension .
. if no type is given for a value param'
the initial set determines its type structurally .
. the values can be
symbols (words), numbers, char strings:
all value types
have literals within the union of these 3 sets .

mis.adda/oop/type`literals/frame.tag as impl'inheritance:
. in a literal that is defining a type by vector
when there is a frame.tag
it is listing who it inherits a body from;
a face.tag is a list of interfaces (obj'c protocols) .
. this doesn't make sense for separation of { head, body }:
the clients don't need to know
where you're getting your body parts from,
so why post it on the head ?
(that's the contract with the client!) .
. primary feature of frame[impl'inheritance]
supertype[polymorphic adt]
superclass is having slots that are callbacks .
[11.9: ie,
it's essentially a generic package,
and secondarily a data.type or type.class .
. it's saying that members of this class are
involved in generic functions;
ie, functions whose impl'details vary across individuals .

adda/oop/unifying class-based frameworks with subtype polymorphism:

. to merge [the obj'c ideas of ] the protocol
and the frame [impl'inheritance]
with that of supertype
you're saying that new subclassers (reusers, b2b or wholesale clients)
can extend the code of the supertype;
ie, [by naming a type's supertype,
you are indicating ] how it decides who to call
and who to convert during biops [.?]
[.?] by including frames, ...
. the way ada uses "new,
is to allow reuse of interface while at the same time
indicating that the new type
is not assignment-compatable with the copied type .
[!] 0911/adda/oop/modular coercion

. consider subclassing as [?] particular generic type
instead of being general
like in obj'c named [?]
eg, supertype`ext,
and the restriction make simpler [?]
like so:
you can only extend an operation, not override it,
meaning any code you assign to an operator
will be merged in a way that is
clarified by doc's and types;
dealloc' by super does dealloc the entire obj,
if your added fields are pointing to a non-trailer space
you need to add how to dealloc your special-needs fields .

. can you mix this idea with supertype
which mixes subtypes for biops?
in case of ext's,
the super doesn't know who its sublcasses will be;
each subclass may or may not [know] each other
so when super defines a biop,
it means it'll treat its own in a private way;
and, if your subclass wants a say,
it can add it;
for is equal sub#1
if other in list of subs I know then case it, else false [.?]
. the start of this idea was from wondering if
one can avoid having to call super
for things like dealloc and init;
how can that be implit [{impl'd, implicit}?],
a recuring theme is how can lang design make simple
having control over staying abstract
and sharing impl details .

11.5: adda/oop/obj'c is complicated by c-syntax:
. adda can simplify syntax by assuming that
all code is sublacssing mananged obj's .
. in the mvc, eg,
there is so much complication
making c'symantics the default .


adda/oop/impl'inheritance helps modularity:
. one reason to use impl inherit
is trying to reuse code without source code
. can class system stay true to metaphore of classifying science objects?

adda/oop/impl'inheritance's role:
. if impl'inheriting is not needed,
what is the best way?
. how are adda's and mac app interface similar?
. the impl'inherit of mac is meant to
hide and reuse a huge event loop:
this huge chunk is the same used in every app
except for the menu pointers and some added menus .
. the delegates (the functions you override)
are providing those pointers .
[11.9: generic package combined with subtype polymorphism
. the adda view is that your app is generally
a server that has an api (app' programmer interface);
and, that api is providing all menu details
(assumes other processes are getting
essentally the same menu as humans get) .
. if an app wants finer control over the gui,
it creates a plug-in for adde,
or it can provide an adde-replacement .
-- adde being the user's agent that translates between
the api and the user's gui .

bk"mac`oop (schmucker 1980's):
. the Schmucker book on mac`oop
has a list of terms used by various systems
and equates them to the "(standard) terms .
. metaclasses are the obj's that manage classes
that in turn manage obj's that are class instances .

todo.adda/oop/terminology/review prior studies:
. prev'work on oop had good ideas:
the meaning of "(obj) is what represents state
as in 2 instances can't be at the same address
without also being the same obj
(but then a subtle bump into unions) .
. what they call obj is really the
subtype polymorphic adt instance .

11.7: web/adda/oop/terminolgy"{frame lang, ...}:

. frame lang
-- that was the name for dynamically building class relationships;
these can be considered a form of set .
-- this is the basis of AI (artificial intel'e)
building connections the way the mind does .

. the class.type has an adt like set.type
classes are sets that build their memberships by
having properties be true of a given obj .

. in oop theory, "(metaclass) means
the type'mgt for classes;
ie, metaclass : class
:: class : obj .
{meta, super} reminds of hyper -- the protocols .

. maybe method x should be impl' of x
(as in meta physics),

. maybe class could be like self in refering to
one's own type .
or simpler is: self is code,
whereas self`{class, type} refers to
other parts of self .

. multi.inherit sybtype is like serving multiple roles;
eg, html is a subtype of text and {graphic, codish}
( that is, it has multi-values depending on
the translation you want ) .

. multi-inherit sublclass simply means
the conjunction of multi-membership predicates .

11.7: bk.adda/oop/hurley`critical thinking:

. try to get vocab from roots (philosophy),
{meta, super, sub, hyper} class .

. terms are {proper, common} names or descriptive phrases
that serve as subj to a truth function {stmt, proposition}
thereby defining who the members of a class are
(a predicate class) .
. terms have {extensional meanings denoted class members}
or {intensional meanings conoted attributes} .
. english"(connotation) actually means
"(subjective connotation)
ie, what experiences the viewer associates with members of a class .
. terms are names of classes;
term`extension is members of class;
term`intension is property of class
-- conventional vs subjective connotations .
. increasing intension means adding more attributes
resulting in decreasing extension .

11.7: adda/oop/rev of terminology:

. adda needs a firm theory of types
to make sure features need not be bolted on later .
. parts of this process are:
( find all relevant definitions;
, find labels for those definitions from significant sources
, (wiki, apple, past notes)
) . however,
the point should not be to make everyone aware of every feature;
ideally, the point of sophisticated features like oop,
is that they make programming very easy .
. the perfect example is the oop version of number
where numbers can optionally be type-constrained
if you'd like to catch errors,
but you shouldn't have to think about how to combine subtypes .
. the main point of today's review is
knowing how to talk about the details .

. a part of terminology is lifecycle:
. when using the number.type,
the system finds the number`primitives .
. if there are other functions used with number-typed operands,
how is the developer adding those later ?
ie, how are add-on libraries associated with primitive libraries?
. ada solved this with hierarchical packages;
but how does it look when viewed from
how things are stored in folders,
and how binary modules can be relinked ?

the concepts (without the terms)

. describe new types either literally
or by describing one type in terms of another
X is a Y except for ...

describe subtypes:

. when reusing interfaces,
you have a choice as to whether the types are
assignment compatable .

. when reusing code`bodies,
you have a choice between getting auto'updates
or freezing the version .

. when depending on generics by giving untyped symbols
[as param's] to a specific set of operations,
there is the concern that symbols are accidently similar
and the operands were accidently sent to the generic .

wiki says:
. subtyping is a relation between types (oop`interfaces)
whereas inheritance is
a relation between implementations
stemming from a language feature that allows new objects
to be created from existing ones.
In a number of oop languages,
subtyping is called interface inheritance.

. subtyping comes from defining a membership by properties,
if all type`properties are true for x,
then x is a member of that type,
a type`subtype includes all type`properties
and has additional constraints .
. by that definition,
type differs from classification in that classes are disjoint,
whereas types are merely abstract interfaces:
an obj' can be a member of any type
for which it satisfies type`properties .

. [oop] emphasized code reuse at the expense of
dynamic inspection at the expense of
static detection.
opportunities remain for applying important ideas
that hopefully will result in
even stronger engineering advantages for oop languages.

[12.25: not sure how much the following
was influenced by that reference]

parametric polymorphism is generic:
. just apply abstract operations to untyped symbols,
then check the symbol's current type
when the operation is being performed .
. unlike the situation for subtypes of number,
there is a generic way for binary operations
to find a suitable method .
say x and y are the operands, and z is taking the result;
then by subtyping
they each can belong to several types: T{x,y,z}#i .
. so given the call f(x,y) -> z
the system has to find a method for f( Tx#i, Ty#i ).Tz#i
if that doesn't pan out,
the system has to find all the methods for f({T1}, {T2}).{T3}
and see if there are any conversions satisfying
Tx#i -> {T1} and
Ty#i -> {T2} and
{T3} -> Tz#i .

. this is much more expensive freedom than is likely practical,
but for completeness, this could be a low-priority option .

12.3: adda/oop/type as membership vs state`range:
. how to model type as member vs state
enum traffic has states (colors)
enum os has members(mac, pc, linux),
how to declare component of /os/./app/./cmd/ .

12.9: adda/oop/type`client`var's:

. recall the sort of type'mgt var's that are used for exceptions:
when a type is used by a subprogram (by declaring an obj' of that type)
it implicitely inherits a copy of var's that the type'mgt declares pub'ly;
it can then define how type-specific exceptions are handled
by modifying its version of inherited exception var's .
. the same type'mgt var's that are used for exceptions
can also be used as implicit parameters of a type's available operation .

. notice how these differ from the class var's of oop
which are shared by class members:
they are being owned by the client of the type,
who is also owner of a subset of the type's members
and these type'var's are shared only among that subset of type`members .

. the typical use for these are preferences in a paint program:
. each window is a new caller of the paint.type;
and then specific to each window,
you specify the brush`width, paint`color, etc .
. when you paint, that act means
calling the paint.function on the current file,
and that function also needs all those preferences,
so it gets them from the caller's pref's .

. a modular subprogram doesn't inherit environs
unless it's part of the interface (the contract);
whereas, a {private, nested} subprogram and a scope.block
do inherit environs,
which in turn inherit copies of type'var's
from any types they are using .

. there are several candidates for what constitutes a type's client:
a coprogram and a remote or modular subprogram are primary clients;
. 2ndary clients include nested functions and scope.blocks,
which are expected to inherit locals of the primary clients,
and could therefore inherit their owner's type'var's .

. how can 2ndary clients have the option of
changing the super.scope's type'var's,
so that when the current scope ended, the changes would remain;
getting a new copy of type'var's that are local to nested scope.block ?

. to avoid having to make such a decision for the user,
the naming conventions should allow a nested scope.block
to refer either to
its own copies of the type'var's,
with values inherited from either the type or the super.scope .
to the copies owned by its super.scope .
. this could come in the following forms:
type`var -- the default (possibly partial) values of the var,
-- as provided by the type'mgt .
cur`type`var -- current scope's var
super`type`var -- inherited scope's var .

. the type'var's declaration by type'mgt can be partial,
meaning that a subprogram is required to initialize atleast the unfinished parts .
. after that, a subscope can implicitely be inheriting
the value of the superscope or explicitely reset values back to type'mgt's defaults .

. when a function gets a call,
the translation to c means that the type'mgt gets this call:
/type/2operand( operation, dst, op1, op2, [caller's type'var's]/.*),
which means that [caller's type'var's]/.*
is a pointer placed in a register
similar to the pointers to stack, and heap .
. any client of a type gets starts its act'rec' with a
declaration of a pointer that points back at the default type'var's,
or if it changes any of them, it has to make room for them all in a local record
and then have the pointer point at that record .

. using the paint example,
in an oop view, types are acting on a primary object,
and thus every obj' should have it's own pref's;
but, in the multi-oop view,
where the class defines membership as
any combination of types that are handled by the interface's functions,
the unit must be whatever corresponds to the user's window .
. or,
you could do both by having both {window, context} pref's,
where right-clicking on an obj' would bring up the pref's
that would apply just during modification of that obj' .

12.9: adda/terms/{self, sub, super}:

. the term"self should remain consistent with {oop, classification} theory;
an active program is an obj' in the sense of their being code and data
that seen as a unit;
but, to say that every subprogram has an idea of self
would be like thinking that a person's every subgoal had a self .
. intuitively, the term"self might refer only to actor obj's;
however, it might also be useful to reserve self as wordpart for meaning
the current location in aggregate having also {sub, super} parts .
. if that use of self doesn't work out,
notice that cur means the same thing, hence {recur, concur} .

. would there be some use within anonymous nested functions
for a {resub, resuper} as well as for a recur ?
. if resuper meant call your caller back,
how do you know what their parameters are ? .

12.9: adda/oop/type`client`var's:

. a type's client var's are a sort of implicit parameters
that it can offer on a per-client basis,
so that each client can customize what the type offers .
. if a client specializes it's client var's
or is required to define them,
then the change will affect future calls made by that client
without affecting other clients .
. the same affect could be had by explicit parameters
where a preference record ptr is passed to
to any calls handled by the relevant type'mgt;
but, the use of implicit parameters is more efficient .

. the client var' ptr is part of the current process context
along with the stack and heap pointers .
. just as a subprogram will access its locals
relative to the stack pointer,
a type'mgt operation will access any implicit param's
relative to the client var' pointer .

. part of the translater's job is figuring out
when there has been a change in type'mgt,
and respond to that by changing the client var' ptr
whenever that type is known to support client var's .

12.10: adda/terms/type`client`vars:
. what had been termed type'var's,
should follow the naming pattern set by
class`instance`var .
. type can be used instead of class
assuming all types are classes .
. the 3 fundamental state locations of an active type are:
type`mgt`rec -- class var's,
type`instance`rec -- instance var's,
type`client`rec -- parameter blocks .

12.14: todo.adda/oop/subtype needs review:
. instead of ada's x.subtype`= /type/
one type constant is "(in): hi.type`= in person;
. or could be better to use sub as a word part:
x.type`= sub./type/ .

12.19: mis.{adda, addn}/log/arf'd part of the adda type-in's:
8.28: adda/oop/private vs public/8.29: revisited:
"(. rather than have the public symbol"(sys)
being the activation record for the type`mgt,
[but then at an arf'd part of the type-in's,
I couldn't make sense of this:]
. if type.classing access sys is still used for call
then just use the type's name;
[so then I couldn't find context for this:]
if the type is anonymous,
then it works something like anonymous recursion
where the recur.stmt is calling the enclosing subprogram .