On 8/3/05, Nigel Hamilton <[EMAIL PROTECTED]> wrote:
> 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.

You're worried that the flow of control could be unpredictable and
then propose this? :-)

Anyway, I think you have an interesting idea for an experimental
language or module.  If it works well, then maybe it can underlie Perl
and be hidden from everyone but the interested user.  That's how we're
putting in most advanced features these days.

Write a Perl 5 module that implements this control style, if you think
it's possible.


Reply via email to