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.

programming in-the-large with c

8.5: news.adda/translate/info'hiding n type-safe linking:

2007 CMod Modular Information Hiding
and Type Safe Linking for C

CMod, provides a sound module system for C;
it works by enforcing a set of rules that are
based on principles of modular reasoning
and on current programming practice.

CMod's rules safely enforce the convention
that .h header files are module interfaces
and .c source files are module implementations.
Although this convention is well known,
developing CMod's rules revealed many subtleties
to applying the basic pattern correctly.
CMod's rules have been proven formally
to enforce both information hiding
and type-safe linking.

subtype polymorphism replacing polymorphic records

4.22: adda/oop/subtype polymorphism replacing polymorphic records:

. the example in [cocoa patterns].book/hierarchy
of using a graphics tree to express subgraphics
reminded me of how expressions use trees:
. generic trees are intuitively implemented as
variant records, (I'm not sure why these aren't called
polymorphic records ...)
and, this had me realizing how oop subclasses
are using their subclass tag
as a variant record discriminant:
[4.28: for example,
an expression tree has an eval operation
for both the branch and leaf variants
of its variant record structure;
therefore, it's a candidate for replacement by
an oop structure:
the branch subclass's eval
has to eval all args's
then apply the given operation;
the leaf subclass's eval
has to return its immediate value .]
. in both the case of oop and of variant record,
the low-level implementation could involve
a tagged record:
a record where one of the fields
is a code indicating which variant or subclass
the current state belongs to .

. to see a record as an ADT (abstract datatype),
imagine its list of components rephrased as
the operations that come with those components .

. show how oop's subtype polymorphism can save space
the way a variant rec's polymorphism can .
[4.28: variant rec's assume
that the size of all variants
is known at compile time;
and if all the sizes are known to be
approx'ly the same,
then the implementation might use
an immediate placement
rather than a pointer .
. among oop cases, it's true for polymorphs (eg, numbers)
that the size of all variants is known at compile time;
but not generally true for evolvers
(because they can evolve after compile time)
so then, polymorphs can benefit from a
tag system that can indicate
whether the obj's placement is immediate
or found by a pointer .
. on the other hand, oop's polymorphism can be
a time waster:
if half the instances
implement an operation as null,
then it would be more efficient to
case the tag
and make the call only when the instance
supports that operation;
that, in fact,
is why oop allows both styles:
oop can do anything a variant record can
by allowing a client to ask an obj'
what subclass or variant
it currently belongs to .
. summary of variant discrimination
vs subclass polymorphism:
. every node visit can either case the tag
in order to decide on operations to apply;
or a visit can simply
use those operations that are
supported by every subclass .
so, when you ask an oop obj' to do an act,
you're asking a subtype
to do its version of the act .]

an interface's value literals

3.25: adda/type literals:
. a full adt description needs both a
set of operations
and a set of value literals .
. definitions of type enum are listing
just the values
because the set of operations are from
the scalar.class,
which by definition include certain operations:
relationals (equality, inequality),
assignment, and functions for expressing values as
an integer or string:
ord is the value's place in scalar order;
val is the numeric encoding of the state;
image is the graphic view of state
-- typically a character string
but can also be an icon:
. every graphic icon has a title (a filename),
and many images have nothing but a title;
eg, to describe the state of color,
you'd use the name of the color without necessarily
mapping it also to a colored block image .
[3.31:
. perhaps the most natural way to show in an interface
that a set of symbols are the type's value literals,
is to express them as the return values of the function:
image()
-- understood to return the type's value literals:
`image.{ v1, v2, ...} .
`val.{ n1, n2, ... } could then show
by correspondence with image,
the mapping of images to codes (assuming val was
contracted to be part of the interface) .]