> > Further more, one can check if a watcher was cancelled - by calling
> > is_active(). So I suggest to note this in the doc as well, e.g.:
>
> Do you want an is_cancelled() method? I could add that, but it didn't
> seem important.
This was my first thought. Then I discovered that the already existing method
is_active() changes its behaviour and could be used exactly this way. But now that
you fixed this, I really suggest is_cancelled(), at least for consistency (there are
other is_state_entered() methods as well).
My point here is an intuitive interface, and I think this is important. I'm going to
explain Event to some people and it sounds better to say "if you manage watcher
objects yourself, you should always take care not to use them after they are
cancelled, which could be checked by the is_cancelled() method" - compared with
this: "you can manage watchers yourself as well, but don't be surprised to see
exceptions if you use one of them after its cancellation".
> > 6) var watchers have a poll attribute which is described with valid
> > values r, w, e and t.
>
> Where do you see this?
In the description of the poll attribute.
> FYI, var watchers only respect the R & W flags.
That is what one would expect, of course. The point is that "poll" is described in
general, possibly when it was used only in io watchers, but that parts of this
description are valid only for io watchers. I would suggest to note this.
> > And, because they have no timeout attribute, "t"?
>
> Timeout is not a problem to add, but no one has requested it yet.
So don't I. My point was that it is documented as a valid "poll" value in general,
why it is NOT valid if "poll" is an var watcher attribute.
But really ... why should the timeout attribute NOT become generally available? This
would simplify the interface, wouldn't it?
> The inactivity watcher is experimental. It is explicitly documented as
> such in my copy of Event.
OK.
> > 8) Could you provide a list of which attribute settings are mandatory
> > for the certain watcher types?
>
> Here is what I wrote:
>
> =item $watcher->start
>
> Activate the watcher. Watchers refuse to C<start()> without sufficient
> configuration information to generate events. Constructors always
> invoke C<start()> unless the C<parked=>1> option is requested. You
> will need to set the parked option if you preallocate unconfigured
> watchers.
>
> Do you still want all the specifics? Isn't it too much detail?
I think this paragraph is okay to start with, but I expect that a new user will ask
immediatley what "sufficient configuration information" is ...
The reason to ask for these details is, as mentioned before, the wish for a clear
interface. Of course Event users are developers and can figure these things out by
trial and error at least, but ... hm!
Hm again. Just a thought: IF there is already such an (even unstructured) list,
could you please send it to me? I could try to include these informations to the
intro article, and hopefully the result will be tables which I could send back to
you if you wish.
> > 9) If I install a watcher and delay the call of loop(), what about
> > events arriving in the meantime?
>
> I don't want to address this question until the Win32 port is done.
Oh! Why? Is there an answer on UNIX?
> I'll upload a new version shortly.
Thank you!
Jochen
