Charles Nutter <headius / headius.com> wrote:
> What's the effect of the EPHEMERAL flag if someone takes an object
> with an attached ephemeral class and starts making singleton changes
> to that object? Do those changes properly flush cache?

No, it's a situation where the user must be careful and not shoot
themselves in the foot.  It is C, after all.

Nowadays since internal.h exists, it would be safer to only expose
ephemeral in the new "internal.h" header and not make it part of the
public C API.

> If this flag only helps cases where you're extending a module with no
> methods, it seems extremely niche...why don't we just reverse course
> on extending these modules at all?

This would break code already written for Ruby 1.9.2.  Otherwise, I
would love to do it (not that I have the power to actually do it).

I absolutely *HATE* the way Ruby extends classes and throws exceptions
for EAGAIN, but there's not much one can do about it.

A better idea would be to get a kgio-like API into Ruby itself and
encourage people to start using that.  kgio itself will never take off
since it's *nix-only and written in C, so it should be moved into Ruby
and the Ruby spec itself if people really want it (without the ugly
"kgio_" prefixes everywhere).

[1] - http://bogomips.org/kgio/

-- 
Eric Wong