I've been reading the Perl6 "type" and method dispatch discussions with
some fear and trepidation.
Just following the linear flow of control through a program can sometimes
be a mind bend. The type inferencing and dispatch system for Perl6 seems
very funky. Throw in some autothreading and Junctions and my brain is
melting. Where is the flow of control going next?
However, it's great to see Roles break down hierarchical OO (sometimes it
just didn't fit). But now all the objects/types/roles in the system hang
together in one big relational blob. How can the flow of control pass
cleanly between all the sub-blobs? How can the sub-blobs interact
polymorphously without melting into one?
I've just read Damian's inside-out object description in his latest book -
which could be the catalyst for this next suggestion .... maybe we can
turn the method dispatch problem inside-out too?
Warning: thought experiment coming ...
Instead of passing the "buck" from object to object via parameter lists
and type inference (traversing OO hierarchies etc) maybe we could ..
Model the flow of control through a program as a simple linear queue of
topic changes. A central "Controller" holds the current "Topic" and guides
the conversation between "Objects"? Rather than the Topic moving from
lexical scope to lexical scope it stays in one place (i.e., it doesn't get
dispatched).
The Controller only discusses the current Topic with Objects that are
qualified to listen (e.g., based on their Role/Type etc). Objects that
earn the ear of the Controller can change the Topic and influence what
happens next. The Controller doesn't dispatch to Objects based on
parameter lists - instead it grants access to the current Topic based on
the Types/Roles of interested objects - messages are not passed around
with traditional parameter lists but via changes in the central Topic.
As a programmer you spend time modelling how your Objects respond to
events and keeping the Controller on Topic. The Topic also contains the
current scratchpad of variables so the need to transfer parameters is
eliminated/reduced - they now form part of the current Topic.
System events (e.g., socket closed) could then propagate into your program
via the Controller. For example, a new topic has arrived, "socket closed
exception" - the Controller then finds an interested object.
In traditional OO models exception objects propagate up until somebody
catches them. Imagine if your program worked like exceptions currently do?
Instead of raising exceptions you constantly "raise a new topic". The
Controller then must decide what object should handle the change in topic
(i.e., who catches the Exception).
Which I think brings me around to the initial problem ... hmmmm.
So on that note I'll:
throw(Topic);
and see if it gets caught ...
NIge
