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).
2012-08-26
Subscribe to:
Post Comments (Atom)
8.19: adda/oop/messaging semantics clarified:
ReplyDelete. the syntax x`f(y)
was recently redefined to have 2 features:
# any component of x can do inout,
whereas y's components are read-only
(these are 2 types of access mode);
# all the components of x are tagged types,
all of which must share a common supertype
that supports x`f(y) .
. this new definition is incompatible with the prior one,
which held that the syntax x`f
could be interchangeable with f(x);
because, interchanging x`f with f(x)
would now change x's access mode .
. why does classic oop prefer to express
f(g(h(x))) as x`h`g`f ?
because, it's then obvious from the text
which functions are being applied to x:
h is just a member of x's interface .
. that feature is handy during assignment
for distinguishing it from equality:
( x`= i ) is not ( x = i )
--[11.9: the software industry has settled on
using 2 different operators { =, == },
while math literature has moved to { :=, = }
for {assignment, equality }. ]
[11.9:
. another improvement by changing definitions
was the previous assumption that the syntax x`f
was the sign for dispatching on a type.tag;
this was inconsistent with my extension of oop
that dispatched on the surtype
of the 2 operands of a binary operation;
eg, (a.int + b.real) -- surtype is Number .
rather that classic oop's ( a`+ b ) notation
that dispatched only on a's type.tag .]
. generally we want the ability to
have any subprogram of a tagged.type
be able to dispatch on all parameters;
but, when allowing this for the syntax f(x,y),
sometimes we might find that x and y
don't share a common supertype;
in that case we fall back to overloading:
find an f from any visible package
that supports some signature in the set:
f(x`typeclass, y`typeclass); [11.9:
failing that,
we would look for some combination of
available conversions that are compatible with
some available f(x,y) . if that is found,
we warn the compiler user about
relying on the use of implicit conversions .]
[8.19: 11.9:
. how do we know 2 types won't
define the same signature?
. there shouldn't be a clash;
because, the compiler will remind the user
that the simplest way to create an interface,
is to provide only operations over self`type,
and then offer conversion routines;
so that users of (string+number)
will have to specify
( str + to.string(num) ) for a string,
or ( num + to.number(str)) for a number .
. but that can only be a suggestion:
interface authors can include any signatures;
and interface users don't have to use
explicit conversions .
. the fallback if users don't take the suggestion
is to dialog them about conflicts;
eg, "( you asked for +(num, str).any;
so, which of these did you mean:
+(num, str).num
or +(num, str).str ? ]