On Mon, Jan 31, 2000 at 06:19:35PM +0100, [EMAIL PROTECTED] wrote:
> > It's more code to write. I prefer not to add features unless they are
> > obvious or requested. Maybe this fits into the category of "obvious?"
>
> I think so ;-) It has a general meaning, and it's more difficult to keep in
> > But really ... why should the timeout attribute NOT become generally available?
>This
> > would simplify the interface, wouldn't it?
>
> It's more code to write. I prefer not to add features unless they are
> obvious or requested. Maybe this fits into the category of "obvious?"
I think so
On Mon, Jan 31, 2000 at 05:26:27PM +0100, [EMAIL PROTECTED] wrote:
> > > 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
> > see
> > 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 e
On Mon, Jan 31, 2000 at 01:08:28PM +0100, [EMAIL PROTECTED] wrote:
> 1) Event manages watcher objects internally. That's why there is no
> urgent need to manage them yourself. On the other hand, if you want to
> do this, it is possible. As a side effect of this, one can have a
> watcher object tha
Hello,
preparing an Event introduction, I started to write down and structure
my knowledge about the module. Here are a few questions and suggestions
that came up (the numbers are only there to structure the questions):
1) Event manages watcher objects internally. That's why there is no
u
