develooper Front page | perl.perl6.language | Postings from August 2005

What role for exceptional types?

Thread Next
From:
Nigel Hamilton
Date:
August 3, 2005 09:16
Subject:
What role for exceptional types?
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


Thread Next


Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About