pioneers of the abstract data type or object-oriented modularization

2021.7.21..8.19: news.adda/lang/
pioneers of the abstract data type or object-oriented modularization/
Wirth 1979`founders of abstract data type were C.A.R. Hoare, P. Brinch Hansen:

. I had recently heard prof Liskov 2013

explaining how she was the origin of the ADT

(abstract data type) back in 1971

when she was working on the Venus system;

http://amerdreamdocs.blogspot.com/2021/07/drbarbara-liskovthe-software-crisis.html

but prof Wirth 1979 claims the idea came from

C.A.R. Hoare and P. Brinch Hansen;

however, he gives no details or a date.

. about the same time that Liskov was working on Venus

David L. Parnas was mentioning "information hiding" 

referring to object-oriented modules

being preferred to functional decomposition.

Dr.Barbara Liskov`the software crisis averted with modularity based on data abstraction

21.6.10:  7.12: news.adda/lang/

Dr.Barbara Liskov`the software crisis averted with modularity based on data abstraction:

. the key to programming in the large 

is modularity based on data abstraction

and that was not obvious before her work,

but now her work is mainstream, so it now seems obvious.

keywords "this", "self", "returned" for adda

 20.10.28: adda/lexicon/this, self, returned:

a discussion about adding keywords to the language.

multi-inheritance

5.10: adda/oop/multi-inheritance:
12.26..27: summary:
. I played around with the idea of mult-inheritance
in 2010/06, 2010/11,  and 2012;
after this latest exploration in 2014/05,
I'm wondering if mult-inheritance is worth it;
because it could easily become confusing
knowing how many roles are affected by assignments .

delegates in obj'c

4.24: adda/oop/delegates/delegates in obj'c:
. in the model-view-controller pattern
the model is acting as a server .
. some servers expect you to
provide as input for their startup
an object that serves as your delegate,
the delegate class provided by the client
conforms to the interface expected by the server
and when the server has to provide
some client-specific processing
it is launching one of the client's delegate's methods .
. this is just like if the server
expected the client to input
a set of pointers to subprograms
but by supplying an object instead,
the included set of subprograms can share some variables
whose state persists between subprogram calls
(instance vars of the obj).

concurrency ideas inspired by obj'c

4.13: adda/oop/co/concurrency ideas inspired by obj'c:
. obj'c has a callback pattern
where a service provider is customizable
by expecting the clients to provide certain functions
that the service provider will call at special times .
. obj'c's callbacks will have a param indicating
which object is the service provider doing the callback
-- apple calls that the msg sender --
but that is generalizable as the caller:
each call is part of a call stack,
and we don't need to include the caller in the parameter
because the system can provide that as stack(-1),
eg, the adda language could reserve the term:
self`caller
( however, notice in pure oop, callers are
always obj's, not subprograms .
when a service provider is calling you back,
you don't want to know which of its subprogram's called you back;
you want a way to refer back to the service provider .
. the key to sorting this out is noticing
when there is cross-module communications .
. are all objects to be treated as separate processes?
)
. is there a distinction between caller and msg sender?
are objects async'ly called ? generally not,
since the call's parameters could be
references to caller's internals;
so, the caller is going to want to
wait for the call to finish .
. even if the callee is not writing to a shared object
the caller has to avoid writing until callee is done,
or it has to be a dynamically updateable type
(2 threads must agree to release as often as possible).
. if not waiting for callee to return,
there must be a lock on the refs target,
when callee is done handling the msg
the system has to notice if any params are pointers
and unlock the targets when the call is done;
ie,
the caller usually knows when a call is done,
because it wouldn't be runnable
unless all its callees had returned;
so, during an async call, the caller is still running
until it bumps into a locked resource,
and when the async callee returns,
the system must provide a notification,
and upon notification the caller can unlock the resources
that it had let that callee borrow,
or the system's notification could consist of
auto'ly unlocking what was shared with the callee .
. unlocking means decrementing an [in use by a callee].counter,
since with async calling concurrently,
there could be multiple readers locking out writers .
... may want to review
what's already been written about this;
but generally,
it would be nice to have a way for the caller
to know when an async callee is done
the async syntax could be
has-returned.flag`= async y`= f(x) .

multi-object modifications

1.15: 6.12: adda/oop/multi-object modifications:
. the object notation: "( object`operation )
is saying that the given object is modifying itself;
whereas, if no modification was expected,
the preferred syntax would be  "( operation(object) ).

in-mode param use cases

12.8: adda/oop/in-mode param use cases:
8.731: 9.812:
. in-mode parameters that are offering values
(vs pointers) don't need an is-constant bit,
since they are copies that the callee can operate on;
in-mode pointers could use an is-constant bit
for describing whether the target can be modified?
the compiler can enforce constancy
by ensuring that the in-mode pointer's components
are passed only to other in-mode param's .
8.748:
. the primary reason for
in-mode param's being pointers
is when the callee expects the value to be
a large data structure,
and is agreeing to treat the pointer's target
as read-only rather than a writable copy .
. but another reason for an in-mode pointer
is that the pointer's target
is under the control of a different process
that will be changing the value in real time .
. so the formal in-mode pointer
needs to declare whether it honors read-only;
if it doesn't and an actual parameter is read-only
there could be a copy-on-write mechanism
where if the callee's code branched to
a place where it wanted to modify the target,
then the pointer was replaced to point to
a local copy of the target .
9.817: conclusion:
. an actual param has several cases:
# is a value (not a pointer):
. the value is copied,
and the callee's local version is modifiable .
# is a ptr real-time modified:
. the callee is getting a newsfeed
so there is no local version to modify
and it is considered read-only by callee .
# is a ptr not real-time modified:
. if the callee decides to modify the local version
one is created on demand (copy ptr target on modify).

subtypes of values vs addresses #terminology

12.10: mis.adda/oop/terminology/subtypes of values vs addresses:
. I'm misusing the term "subtype"?
let's review,
2010/04/polymorphic-vs-evolutionary-subtyping.html
2012/02/def-supertype-supratype-surtype.html
2012/10/infratypes-of-surtypes-phyla-of-taxa.html

"you mean that N is a subset of Z,
but then that implies Z is a subtype of N?
that depends on the direction:
you can represent any N value with a Z,
but if I need the address to an N,
a Z is no substitute because it
doesn't enforce my range constraint ."

so, "subtype" is the right word sometimes .

# for passing a value in:
. if the actual is a subrange of the formal,
then it will fit, and the actual is
serving both types, and that's what a subtype is .
. if the actual is a
constant version of the formal's type,
no changes are needed so input is accepted,
and constant T is a subtype of T here .

# for passing a value out:
. if the actual is a subrange of the formal,
the formal is saying
"I might send out a large number"
and the actual is saying
"I can't handle large numbers";
therefore access to subrange of T
is not a subtype of access to T .
. if the actual is
a constant version of the formal
the constant fails to accept any of the output;
therefore access to constant T
is not a subtype of access to T .

. after reading notes on terminology
I decided on yet another revision to that:
"surtype" is the system's typeclass
(pointer, valuetype, subprogram, aggregate, ...);
because, a surtype can classify
every object found in a programming environment .
. a polymorphic typeclass like number.type
is an example of a "polymorphtype" .
. the types {N,Z,Q,C,R}
are all the "morphtypes" of number;
"morphsubtypes" are constrained subtypes of morphtypes;
"infratypes" are implementations of a morphtype,
eg, the machine type Z32 (32-bit integer)
may implement a subrange of morphtype Z .

constant.subtype vs mutable.subclass

adda/oop/mutable types as subclasses of a constant type:
10.20:
. I'm reviewing Apple's Cocoa Objective-C,
and noticing again a mutable type is
seen as a subclass of a constant?
it would seem more intuitive if
constancy was an orthogonal attribute:
any type can optionally be described as
constrained to a constant state .

type.tags for aggregates

10.17: adda/oop/type.tags for aggregates:
[12.8: intro:
. if we were to have a generic aggregate,
what would its type.tag look like?
(the purpose of a generic aggregate
is having something that packs objects together,
and can be easily created and traversed .

target-owning vs aliasing pointers

12.7: summary:
. this explores types of pointers
needed for adda's space-efficient style of oop,
and support of safe pointers .

mem'mgt for a top-down stack layout

9.4: adda/mem'mgt/top-down stack layout:
[11.23: intro:
. the adda`oop system (unlike other oop impl's)
seeks to avoid generating garbage,
and that requires that when a function returns an object,
the return-obj's needed memory was allocated by the caller,
and then the function was given a pointer to that memory .
. that means assignments and function calls
are fused into one operation;
y`= f(x) is implicitly:
y`= f(x, ptr to y),
and this is true even when y is a parameter:
g( f(x) ) is implicitly:
stack g(y); stack f(x, ptr to y); call f; call g .

semi-type-specific subheaps

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

substitution principle

8.21: adda/oop/type/substitution principle:
. when a parameter is type rectangle,
then it can be assigned any rectangle
including a square;
because, a square is rectangular .
. classic oop has had a problem with that,
so, how do we sort out our subtypes
from this jumble of subclass confusion?
[11.9:
. the solution I've come up with
is known as Changing The Language:
ie, rather than assume a type.tag is constant;
we assert that related types
are expected to have a common surtype;
eg, for a var constrained to Number.type,
it will have a constant surtype.tag;
but, it will also have a modifiable subtype.tag,
that can vary within {N,Z,Q,R,C}
(unsigned, int, quotient, real, complex).
. a var constraint can be a subtype too:
eg, for a var constrained to Real,
it can only vary in {N,Z,Q,R};
ie, the subtypes whose domains are
subsets of Real's domain .
. and, as usual for non-oop,
if a var is constrained to a definite type, such as float32,
then both the surtype and subtype
are going to be constant
(hence the obj will be untagged);
but, since the surtype is Number,
and float32 is understood to be a subtype of Real,
you can ask for (float32 + int)
and multi-dispatching will still work .]
. in order to be a subtype of rectangle,
an object that is tagged as being a square
has got to be re-taggable as non-square
in the event that the rectangle interface
asks it to modify itself;
ie, a type that inherits from rectangle
and then adds the constraint
that it be a square too -- forever --
has decided to nix support for type compatability,
which contradicts the idea of inheritance .
. to be a subtype (ie, support type compatability)
the inheritance needs to work like this:
my subtype named square
has the properties of the inherited rectangle
but includes the constraint width = height .
. if you ask me to break that constraint,
then I'll re-type.tag myself as a rectangle
(rectangular but not square).
[11.9: corrollary:
. if a var is constrained to be a square,
then the only rectangle it can be assigned to
is an unmodifiable one;
being assigned to a modifiable rectangle,
could potentially violate the type constraint,
and should result in a compile-time warning .
. this isn't a fatal error though;
because, the user could expect that
squares will grow in only a square way,
-- as would be the case for doublemy(rectangle) --
or the user may want to handle the exception
by trying another algorithm;
therefore, the warning should remind the users,
that they appear to be depending on
either having exceptions handle
the type.constraint.error,
or having the rectangle operation
not violate a square's subtype.constraint .]

obj'c categories and Ada's hierarchical pkg

8.14: adda/oop/obj'c categories and ada hierarchical libs:
reviewing:
2012-01-31 Objective-C Categories
1.20: adda/type/obj'c categories:
. Apple is using the obj'c Category for MVC separation;*
eg, string has many uses in a command-line interface,
so it exists in the core package without any methods for
drawing on a gui;
categories are then simply extending that string type,
instead of having sublclasses reuse that string type
in yet another type;
so just one type can exist
yet with  relevant parts in different packages .
* see { Buck, Yacktman}`Cocoa Design Patterns

todo:
. isn't that use of categories needed only because
the designers were assuming certain requirements
that are demanded only by the current oop model?

. if your string wants to express gui-specific tricks
such as appearing in a particular font,
or being arranged so as to follow a curve,
that need should be served by the use of a drawing record
which then has a string as one of it's parts .
(ie, it's ok to have 2 different classes !)
--
. a main point of the book"design patterns

was to critique oop's use of subclassing;
and, that criticism might apply equally well
to this use of categories;
but, generally, categories do have a good purpose:
they allow separate compilation of class extensions
without having to recompile the original interface
which might then require a recompile of
all the clients of that interface .

. this reminds of Ada's hierarchical libraries,
in Ada you can reuse oldlib's module
with the syntax:
package oldlib.additionalmethods
(by including oldlib's name like that
within your new package's name,
your new package includes the binaries of oldlib ).
. now current clients of oldlib
still don't have additional methods,
but, future clients of oldlib.additionalmethods
will have access to both modules
with that one import .
. obj'c categories by contrast,
allow you to add the same new modules
but this addition will also be affecting
current clients!
-- the category's method has access only to
the target's interface, not its internals;
so, a category can't fix every bug;
yet it can create bugs because it can
override system methods .

. I have 2 competing ideas on this:
# we should be able to describe in adda
any idea of any other language;
vs,
# we should not be supporting the use of ideas
that are either complicating or insecure .

here's how the the Category idea might be impl'd:
. when a datataype agrees to be modified by categories;
then at run-time, the type mgt is a modifiable object
and, it provides a dictionary
where you can see if it supports a message .
. it can dynamically add entries to this dictionary
(allowing it to support new messages),
and it can change method addresses
(allowing it to update the methods of old messages).
[10.8:
. now all we need is an uncomplicated way to
decide which types are so modifiable .
. perhaps a type wishing to participate
could declare one of its components to be
a dictionary with a standard name
(perhaps SEL, in honor of Obj'C);
then anytime a message is unrecognized,
the run-time would check SEL for the method .
11.8: correction:
. in order to work like an obj'c category,
it has to check SEL all the time,
not just when a message is unrecognized,
in case one of its methods got overridden .]

self's id

8.11: adda/oop/self's id:
7.28: intro:
. the expression tree being sent to number's type mgt
contains ptrs to the symbol table nodes;
and, those nodes include type tags .
. the symbol table is constant,
being part of the function's template;
the code points to symbol table nodes,
and then those nodes point to the stack,
or have immediate data if constant .
8.11:
. how does an object know its own id?
an expression tree sent to a type mgt
has a context (process, act'rec)
that tells it who the caller is,
and all the obj references in the expr'tree
are relative to that context .
. messaging an obj means calling its type mgt,
and then that type mgt is calling the methods
which then have access to the current context
as a global just like in assembly language
where programs have access to a current
stack pointer and program counter .

infratypes of surtypes, phyla of taxa

8.13: adda/oop/rethinking terminology:
. I have terminology for biop (binary operations) oop
arranged as supertypes existing as
one of fixed number of subtypes;
eg, Number is a supertype because it manages the
binary interactions between the following types
which are therefore called subtypes of number:
integer, real, decimal, rational, irrational, complex .
. classic oop hasn't played well with biop's:
being objected-oriented has meant that
(obj+x) had to be expressed as (obj.+(x))
and then obj's type, say int, needed to have
(+)-operations for each possible numeric type
(int, real, rational, irrational, complex);
what we needed was multi-dispatching:
where (obj+ x) gets sent to the supertype,
which finds the right subtype to handle it .

. the notion of subtype
can also include range limits .
. there are naturally limits imposed by
the numeric types that machines provide,
such as what can fit in multiple of bytes;
eg, int8, int16, int32, float32 .
. within my theory of oop,
these might be called infratypes,
for reminding of the term infrastructure .
[10.5:
. infratype is a relative term:
regardless of whether it's a cpu type,
or a type you reused from a library,
an infratype of T.type is any type that has been
reused for implementing T .
10.7:
. I'm realizing that infratypes
should be supported by the type.tag
(simply because we should support
space-efficient numerics,
and we do that, then we need to know
which infratype we're using in
(8, 16, 32, extendible);
therefore,
what I've been calling subtypes
(in the biop oop context)
can instead be called ideal infratypes
(in contrast to optimized infratypes);
likewise,
what I've been calling the supertype
can instead be the opposite of infratype:
that seems to be the word: surtype .
-- also some extra checking just now
shows that the idea I'm trying to convey,
is the same as that found in the words:
{surname, surface} -- the outermost part .]

[10.5: 10.7:
. in contrast to the ideal infratypes
that are designed by mathematicians,
the optimized infratypes are chosen by the
intersection of what types the platform provides
and what is of use by the
constrained versions of the ideal infratypes .

. there is a relationship between
subtypes and infratypes:
. within a polymorphic type,
infratypes are the type's possible forms (morphs);
whereas an value whose type is a subtype of T,
can be used anywhere a T-typed obj is permitted;
but the reverse is not true:
if you have a variable obj whose type is a subtype of T,
it cannot be used anywhere a T-typed obj is permitted;
rather the replacing obj must be able to handle
every value and every operation
that could be handled by the obj' it's replacing .

. a surtype has a finite set of ideal infratypes,
ie, types distinguished by having differences in
either the allowed set of operations,
or the data format of the current state .
. within each ideal infratype,
we then have a possibly infinite number of
additional subtypes
according to constraints on
value attributes, eg, on the value's range,
or the scientific format's number of digits,
or on the number of fraction digits .]

obj' messaging to clarify what's functional

7.28: adda/function/
oop's obj' messaging as a syntax for inout params:
[8.8: 8.16: intro:
. the usual way to manage objects is to
define their interface with a datatype declaration;
eg, t.type: ( ... ) -- that interface can include
both subprograms ( f( x.t ) )
and obj'messages  ( x'f ).
. up to now, that interface declaration
was the only place where we could
define obj'messages;
whereas, subprogram could be defined anywhere:
. there are various declare blocks
( package, record, subprogram, etc).
that can instantiate objects of type t;
eg, (.int:  ... )
-- that's a block that returns an integer;
and, anywhere an object can be declared,
we can also declare subprograms that are
local to the current declare block .]

declare blocks can declare obj'messaging:
. obj'messaging can be seen as
a special style of parameter,
where f(inout x) is instead written as ( x`f ).
. in the context of a type declaration,
( x`f ) is declared simply as ( `f );
because, x is assumed to be
any of the datatype's instantiations;
so, we know what x's type is,
but in a subprogram's declaration of ( x`f )
x's type would not be known;
so, the sub's declaration
would look like this: ( (x.type)`f );
and, a generalization of this would be
(x.type1, y.type2, etc)`f
which is useful for making it obvious that
x,y,etc are all inout parameters;
then we can reserve the syntax ( f(x) )
for functional uses of x,
ie, where ( f ) is not modifying x
nor modifying anything x can access;
ie, if you want to pass a pointer, p,
for the purposes of modifying p's target,
then the needed syntax is p`f, not f(p).

signals

7.27: adda/cstr/signals:
7.30: intro:
. pyqt signals are a system of inter-object communication;
any object can emit a signal
to convey that some event has occurred;
and, any other object may connect a signal handler
to be launched whenever a particular object
raises a particular signal .
. signals can return any sort of record,
and the corresponding signal handlers
are expected to declare their parameter's type
to be the same type as the signal's returned record .
. pyqt sees signals as launching slots
and then the act of connecting a signal handler
is filling such a slot with a subprogram .
. there can be multiple connections to a slot,
so the slot is often filled with multiple handlers .