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

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

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

oop's multi-dispatch

6.5: adda/oop/multi-dispatch/ working with obj'c:
[6.17: intro:
. according to the wiki,
the term"multi-dispatch refers to
something other than what I assumed it to be
so, I will now explain the diff's .

. everybody agrees on how polymorphism happens
when there is only one argument:
when you write f(x) you mean
x can be any type as long as
x's type defines a function f .
. you don't really know which procedure or method
is being used to define the function f
until you ask x what its type is,
then you use the f-procedure defined by that type .
. that is called dynamic dispatch;
the term "(dispatch) is being used in the same way
as "(taxi dispatcher),
whose decision of which taxi to send
depends on which taxi is free and closest;
likewise, a function call dispatcher
determines which procedure to send the arg to,
and bases its decision on
both the function name,
and the argument's type .

. if the arg is binary,
then a multi-dispatch system has to find
a procedure that is typed for that particular
combination of arg types;
and most such systems use function overloading;
ie, they overload a function's meaning;
eg,
there are many types of cars and motorcycles;
and how a collision turns out
depends on both types;
so then, for each type combination,
you have to define a new procedure
for the car-motorcycle collision function;
that means, for example,
that every time you create a new type of motorcycle,
you have to define as many new collision procedures
as there are types of cars .

. the multi-dispatch system I have in mind
does not use overloading;
rather it expects multiple args to share some supertype;
so, for the cars and motorcycles example,
they could simply share the physics type;
which defines its members as having
a mass and a velocity;
the collision procedure asks both arg's
for their mass and velocity
and then calculates new velocities for each .
. it then sends each arg a message
to change itself to the new velocity,
which each can do with its own version of
a velocitychange(x) procedure .

. that was a simple case because the multi-arg function
could be reduced to a multiple of single-arg functions;
a more complicated case can be found in numerics,
where a binary operation doesn't resolve into
2 unary operations;
. for example, say you had a numeric supertype
that includes only reals and ints;
# it can be overloading the addition function:
+(int, int),
+(real, real)
+(real, int),
+(int, real) .
# or it can use coercion:
it checks to see if types differ,
and then converts one
so both are the same type:
+(int,real) then means a call to
+(real,real);
it then checks whether the destination
is able to accept a real,
or if the destination has a function for
converting a real to its own type .

. now lets say another type, Rational,
is declared to be a subtype of numerics;
this means the supertype procedure for
handling binary operations
has to be updated:
# overloaders then have many more cases to deal with:
{int,real,rational}
x {int,real,rational}.
= 9 cases instead of 4 .
# coercers have another rule to add:
if types differ, then convert ... to ...:
{int,real} to real
{int,rational} to rational
{real, rational} to real .

. in the case of numerics there is a limit to this:
every imaginable subtype of numeric
can be expressed as subtypes of
just these subtypes:
{int, real, rational, complex}
x size-{1,2,4,8byte, huge};
so, for example,
we can declare rainbow to be a subtype of real,
and then the numeric supertype can
-- without ever knowing about rainbows --
see from its type declaration
that it must have a
convert rainbow to real procedure;
and, if a destination is type rainbow,
it again knows from the rainbow declaration
that this destination
has a real assignment procedure .
]-intro
[6.8: 6.17:
. as part of developing for mac,
obj'c features the usual dynamic dispatch .
. the sort of multi-dispatch I have in mind
would fit within mac's type-tagging system;
so for instance,
numerics would have 2 type tags:
# one says it's a subtype of mac's NSobject,
# another is private and indicates
which subtype of numeric it currently is .]