oop (obj'oriented programming)

8.16: adda/oop/avoiding unnecessary polymorphism:

. when is polymorphism required?

[12.19:

. 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?

[12.19:

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') .

[8.29:

. 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 .

[12.19:

. 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:

first:

. 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 .

2nd:

. 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 .

so,

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 .

[12.23:

. 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 .

10.16:

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?

adda/oop/obj'composition:

. 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 .

10.16:

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 .

10.22:

adda/oop/category:

. obj'c relates the word category to classifications

. I recall from philosophy that category had a particular meaning:

eg,

the category of quantity includes:

{ nullity, unity, infinity, 1/infinity (infinitesimal),

cardinal, ordinal, complex, ... }

--ref:

. 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."

10.22:

adda/oop/type vs subtype:

summary:

. 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' .

sci:

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 .

[10.28

. 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

10.28: bk.engl/subtype:

http://en.wikipedia.org/wiki/Subtype_polymorphism

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.

10.23:

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),

10.23:

sci.adda/oop/supertype:

. num.supertype is < subtypes: Q, Z, N, C, R ...>

todo:

. 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 )

[10.24:

. 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) .

10.29:

. 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 .

]

10.24:

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 .

10.25:

adda/oop/sizing.tags:

[11.2: intro:

subtype.tags -- in contrast to type.tags

which identify who mgt is --

are used internally by type'mgt to distinguish between

impl'variants;

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;

whereas,

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) .

[11.2

. 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;

however,

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

[11.2:

. 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.

10.28:

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 .

[11.3:

. 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 .

] .

10.29:

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

vs,

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;

whereas,

a face.tag is a list of interfaces (obj'c protocols) .

[11.9:

. 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]

vs

supertype[polymorphic adt]

is

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:

10.29:

. 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

10.31:

. 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;

eg

dealloc' by super does dealloc the entire obj,

but,

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;

also,

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;

eg,

for is equal sub#1

says

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 .

11.7:

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) .

[11.8:

. if an app wants finer control over the gui,

it creates a plug-in for adde,

or it can provide an adde-replacement .

12.25:

-- 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 .

Subtype_polymorphism

Parametric_polymorphism

Behavioral_subtyping

Duck_typing

Design_by_Contract

Covariance_and_contravariance_(computer_science)

Delegation_(programming)

Inheritance_in_object-oriented_programming

Comparison_of_programming_languages_(object-oriented_programming)

http://doc.cat-v.org/programming/bad_properties_of_OO

Covariance-and-Contravariance

. 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 .

news"subclassing as design by contract:

. 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

modularization;

and,

dynamic inspection at the expense of

static detection.

Therefore,

opportunities remain for applying important ideas

that hopefully will result in

even stronger engineering advantages for oop languages.

Behold the power of parametric polymorphism

Adding generic types to Java

By Eric Allen, JavaWorld.com, 02/01/00

[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

eg,

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

either:

changing the super.scope's type'var's,

so that when the current scope ended, the changes would remain;

or:

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 .

or,

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,

then

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 .