On Thu, Jan 20, 2000 at 11:44:52AM -0500, [EMAIL PROTECTED] wrote:
> JNP> Hm. I'm not sure. Certainly, it is reasonable to clear the fd like:
> >>
> JNP> $io_watcher->fd(undef);
> >>
> >> would that stop/cancel the watcher? what effect does it have other than
> >> to clear the attribute?
>
> JNP> IIRC, it is like calling $io->stop.
>
> but if the fd is erased, could you restart it?
Sure.
> JNP> Are you saying that you want a warning if that happens in the
> JNP> constructor?
> >>
> >> i think that is what happened so it looks like a good place for a
> >> warning. makes no sense to do an io event on an undef fd.
>
> JNP> Presently, all attributes are available via the constructor in
> JNP> the same manner as the function interface. I'm not sure I want
> JNP> to break the symmetry.
>
> i don't think that applies. a constructor can and should check things
> that a attribute method doesn't have to. creating an io event with no or
> an undef fd should be a fatal error or warning. undefing it later via the
> attribute should be a cancel and not a stop as there is no fd to watch.
Hm. I have found use for more flexibility. Creating a watcher is
relatively heavy weight. Being able to reuse watchers for different
fds is a useful option.
> on a similar note, i create write events and immediately stop them. this
> is so all you have to do later when you have data to write is to start
> them.
Oh, I see.
> what about adding a stop attribute to the constructor so i don't
> have to make the extra call to stop. it is a common idea as write events
> will be triggered immediately (in most cases on sockets) after creation
> which is not always what you want.
I don't want to change the default. How about a new attribute in the
constructor?
Event->io(..., parked => 1);
Is there a better name than "parked"? "Suspend" already has meaning.
> it is not clear from the docs which
> attributes are methods only and which are constructor only and which are
> both.
> that could be marked in the docs as well. you say most can be done
> both ways but as with the fd one, it has slightly different behavior in
> the constructor vs. the method (constructor blows up on undef fd, method
> does a stop). these differences need to be documented.
Good point. I'll add that to the TODO list.
> as i get into this more and more i will be pushed into a rewrite of the
> event.pm docs. kick me on this. it is definitely something i have on the
> medium term schedule.
--
"Does `competition' have an abstract purpose?"
via, but not speaking for Deutsche Bank
