Re: data() problems

2000-04-21 Thread Jochen Stenzel
>How about if I rename the new implementation of data() to private()

Re: data() problems

2000-04-21 Thread Jochen Stenzel
>How about if I rename the new implementation of data() to private(), >and then reimplement data() without the fancy caller() trick? Would >that satisfy all parties? Yes, this would be a good solution, clear and flexible. Jochen

Re: data() problems

2000-04-20 Thread Graham Barr
On Thu, Apr 20, 2000 at 06:52:29PM -0400, Uri Guttman wrote: > > "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes: > > JNP> On Thu, Apr 20, 2000 at 02:22:25PM +0100, [EMAIL PROTECTED] wrote: > > >> In otherwords there should be two methods. One for the user, say > >> data(), and o

Re: data() problems

2000-04-20 Thread Uri Guttman
> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes: JNP> How about if I rename the new implementation of data() to private(), JNP> and then reimplement data() without the fancy caller() trick? Would JNP> that satisfy all parties? this is just the two method solution proposed by g

Re: data() problems

2000-04-20 Thread Joshua N Pritikin
On Thu, Apr 20, 2000 at 06:52:29PM -0400, [EMAIL PROTECTED] wrote: > JNP> On Thu, Apr 20, 2000 at 02:22:25PM +0100, [EMAIL PROTECTED] wrote: > > >> In otherwords there should be two methods. One for the user, say > >> data(), and one for sub-classes that want to ensure data integrity, > >

Re: data() problems

2000-04-20 Thread John Salmon
> "Joshua" == Joshua N Pritikin <[EMAIL PROTECTED]> writes: Joshua> Heh, I was pondering this all day. Joshua> Shall I add a note in Event.pod mentioning that data() is Joshua> meant only for implementors of event watchers? Yes. I've experienced major frustration with OO documentation tha

Re: data() problems

2000-04-20 Thread Uri Guttman
> "JNP" == Joshua N Pritikin <[EMAIL PROTECTED]> writes: JNP> On Thu, Apr 20, 2000 at 02:22:25PM +0100, [EMAIL PROTECTED] wrote: >> In otherwords there should be two methods. One for the user, say >> data(), and one for sub-classes that want to ensure data integrity, >> say private_d

Re: data() problems

2000-04-20 Thread Joshua N Pritikin
On Thu, Apr 20, 2000 at 02:22:25PM +0100, [EMAIL PROTECTED] wrote: > On Thu, Apr 20, 2000 at 08:02:02AM -0400, Joshua Pritikin wrote: > > On Thu, Apr 20, 2000 at 11:39:07AM +0200, [EMAIL PROTECTED] wrote: > > Sure, except that it is not easy to determine the correct package from > > inside Event::

Re: data() problems

2000-04-20 Thread Graham Barr
On Thu, Apr 20, 2000 at 08:02:02AM -0400, Joshua Pritikin wrote: > On Thu, Apr 20, 2000 at 11:39:07AM +0200, [EMAIL PROTECTED] wrote: > Sure, except that it is not easy to determine the correct package from > inside Event::Watcher::init(). > > I don't know how to fix this, but I can add a warning

Re: data() problems

2000-04-20 Thread Jochen Stenzel
Hello, > Sure, except that it is not easy to determine the correct package from > inside Event::Watcher::init(). This could be avoided by a global data attribute but well ... I read the discussion of yesterday again and understand somebody could have a need for package specific data storage. We

Re: data() problems

2000-04-20 Thread Joshua N Pritikin
On Thu, Apr 20, 2000 at 11:39:07AM +0200, [EMAIL PROTECTED] wrote: > thanks for this new release. One remark: it is possible to say now (debugger >session): > > DB<1> $io=Event->io(parked=>1, data=>[qw(a b c d)]) > DB<2> x $io->data > 0 undef > DB<3> $io->data([qw(a b c d)]) > DB<4> !