New iteration over the ev++ improvement patch.

[Leandro Lucarella]

Marc Lehmann, el 18 de enero a las 06:08 me escribiste:
> On Thu, Jan 17, 2008 at 05:08:16PM -0200, Leandro Lucarella <llucax at gmail.com> wrote:
> > Well, after all the talking and thinking, this is what I came up with.
> > 
> > Main changes:
> > * The use of exceptions is now optional (configurable via
> >   EV_CXX_EXCEPTIONS). I don't know if:
> >   #define throw(exception) throw (exception)
> >   is valid preprocesor code though =)
> 
> the "recursion" is fine, overriding throw isn't, because:
> 
> a) you sometimes use a zero-argument form of throw()

Not in ev++.h and throw is #undef'ed when the file ends.

> b) overriding throw isn't really legal

Where did you found that?

> c) never override stuff the uer validly might have overridden herself already

This goes against b), but well, is a valid argument. =)

> >   - No check is done when creating a default_loop to see if one is already
> >     created (could be trouble if ev_default_destroy() is called more than
> >     once?).
> 
> right now, calling ev_default_destroy twice is a bug. this is safe, however:
> 
>    ev_default_init (0); ev_default_destroy ()

Ugly hack, but clever =P

> I think at first we should do it that way, we can simplify later,
> together with changing ev_default_* into aliases to the ev_loop functions
> internally.

Ok.

> > * A new function ev::get_default_loop () is provided to get a loop_ref to
> >   the default loop. Once again, no check is done to ensure this function
> >   wont get called before actually creating the default loop.
> 
> Can't help it, I still am not sure we should provide an actual default
> loop wrapper, as I think the default loop is a shared resource that is not
> controlled by any one instance.

In this scheme, the lifetime is controlled by an instance. But I think
default_loop struct could be gone (and get_default_loop () renamed to
default_loop () to mimic the C interface, but getting a loop_ref instead
of a ev_loop*). I like the instance-way though.

> > * loop_ref::fork() is now named loop_ref::fix_fork().
> 
> try post_fork, it doesn't really fix any fork thing :)

Ok, so you had a suggestion after all ;)

> > * ev::time() is now named ev::now().
> 
> bad idea, now "now" means something for C, and something else for
> C++.  I would expect ev::now() to do mostly the same as ev_now ().

As you said, I think ev_time should be ev_now and ev_now should be
ev_loop_now. This could start the path to move that way.

> > * ev::sleep() is now named ev::delay() (stolen from SDL ;).
> 
> ah well :)
> 
> I wonder wether we shouldn't use some prefix instead instead of renaming
> all symbols.

I don't really like prefixes, I prefer renaming in this case. At least
could you consider just an underscore? sleep_, fork_, time_? I know you use
that naming convention for "private" methods but is a used naming convention
for variables with keyword names for example. I still prefer nice renamed
names than straight ugly ones. For time, I think now () is the right name,
and is the C API that should be fixed :), for fork () I think post_fork ()
is right too, because if you aren't fixing anything, you are not forking
anything either, and delay () it's not such a bad name.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
ADOLESCENTE MUERE DESNUCADO POR TRATAR DE AUTOCHUPARSE
	-- Cronista TV