On Tue, Aug 10, 2004 at 10:00:34AM -0400, sungo wrote:
> On (08/06 01:57), [EMAIL PROTECTED] wrote:
> > ZipEvent=>$mutter
>
> > Now the point I've been raising for several years : say I want the
> > event posted to another session, how do I specify that?
>
> I propose a common nomenclature.
>
> FooState : a subroutine reference. the contents of the state to be
> executed when Foo happens.
>
> FooEvent : an event name in the current session. primarily used by
> wheels and other such leeches that attach to the instantiating session
>
> FooPointer : (??) a PRI (POE Resource Indicator, arent i clever? :)
> which can indicate the event in the session and perhaps even the kernel
> where we want notification of the Foo event.
Some people will want to use FooState, and others will want FooEvent,
and they'll all have perfectly good reasons for doing it. Some
component authors will support both, creating FooState and FooEvent
parameters. And people will mix them up, using FooEvent => \&callback.
My current favorite callback naming scheme is "on_foo", as in
on_foo => $do_something,
where $do_something represents an event to fire, a callback, or an
object or class method invocation. This lets people do things
interchangeably:
on_dasher => "event", # whatever syntax is eventually decided upon
on_dancer => \&callback,
on_prancer => [ $object, "method" ],
on_vixen => [ $class, "method" ],
Internally, the base component class might call
$self->callback("on_vixen", @stuff). The base class magic would do the
right thing based on the callback type.
This syntax has the benefit of being compact, but it seems messy and
limited in the the same way POE::Session->new() is. Plus it puts a
burden on the user to remember which syntax means what.
One way around it would be to tag callbacks with a type:
on_dasher => [ event => "event" ],
on_dancer => [ callback => \&callback ],
on_prancer => [ object => $object, "method" ],
on_vixen => [ class => $class, "method" ],
Another possibility would be to use adapter classes:
on_comet => Undecided::Ev->new("event"),
on_cupid => Undecided::Cb->new(\&callback),
on_donner => Undecided::Ob->new($object, "method"),
on_blitzen => Undecided::Cl->new($class, "method"),
Or something.
The adapter classes seem more flexible than having the magic inside a
base component class. It lets users derive new callback classes without
mucking around in the larger component code. A quick example: Someone
might need callback chains. They could derive Undecided::Cb::Chain from
Undecided::Cb:
on_stupid => Undecided::Cb::Chain->new(
Undecided::Cb->new(\&callback),
Undecided::Ob->new($object, "method"),
Undecided::Cl->new($class, "method"),
Undecided::Ev->new("event"), # probably only valid as the last item
),
On the component author side, there might be $on_comet->execute(@args)
that does the right thing based on the object type.
Or something.
--
Rocco Caputo - http://poe.perl.org/
