On Sun, Jan 23, 2000 at 12:52:17PM -0500, [EMAIL PROTECTED] wrote:
> maybe. i will run it by damian to get his take anyhow. at least document
> that so i feel better about it.
OK
> but the direct access of the hash is not cool.
> adding methods via a public and documented path is sorta ok. but
> it still means that my new methods KNOWS the internals of the watcher in
> that it will access the hash part (even if it is not used).
Your brain isn't twisted enough. The reference is a hash only because I
made it that way by default. The event magic can be attached to any
kind of reference. For example, see t/attach_to.t.
> so adding a
> data method to your code would seem to me to be the cleanest
> approach. one simple method and i can store all the data i want any way
> i want it and never worry about implementation or naming issues.
>
> please?????
Sure, but you still haven't convinced me that it is necessary. ;-)
> in my c based event loops, i always had a data pointer in the events. it
> made the api very simple and no internal knowledge was ever needed. but
> that assumed 2 separate 'objects', the internal event and the external
> data. with event.pm in OO form, you can't do that without a data method
> as event uses my object for a callback and i callback another higher
> object so i have to encapsulate them all.
Yah, yah. I understand what you are saying but I think that Event
already provides it.
> this gets confusing in any case. i need a separate OO layer above
> event.pm for the api i want so the objects i pass to cb =>[] have to be
> mine and not the user's. so i need encapsulation even if you gave me the
> data method.
Granted, but I agree that it is a worthy goal to try to minimize the
number of indirections.
--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank
