Front page | perl.perl5.porters |
Postings from December 2008
On Sat, Dec 06, 2008 at 11:15:09PM +0000, Matt S Trout wrote: > On Mon, Nov 24, 2008 at 04:36:01PM +0100, Rafael Garcia-Suarez wrote: > > > 4: HvMROMETA()/Perl_mro_meta_init()/struct xpvhv_aux/cache_gen > > People's interest in this seems to be because of > > HvMROMETA(stash)->pkg_gen > > and > > HvMROMETA(stash)->cv_gen > > - mro.pm exposes the former but not the latter, and if you're accessing these > then it's generally for speed so going through an XSUB is suboptimal. > > I can see not wanting to make the macro's dependencies public, though - what > if we just supplied a function that wrapped it? It's a while back, but I think that my intent was that (currently) the layout of the actual structure is to be considered opaque, hence macros that access it directly also are. Part of the reason being that really the MRO interface was intended to be pluggable, but currently it isn't. I think that we got it right enough in 5.10.0 that it can be done without changing anything, but we won't know that until we try it. But if we start providing APIs to access something that isn't finished, we might remove some flexibility that we still have. Specifically, I'd like to see the C3 parts of mro.c move into ext/mro/c3/ (or something like that) and be dynamically loaded as a side effect of use mro 'c3'; That way, we prove we have a working pluggable system, at which point, the structures we get are good enough, and can be public and frozen. I'm not sure how much it would take to do that, and my non-committal private list of things I might (or might not) do after 5.8.9 escapes doesn't have that at the top. Specifically, at the top, is the 5.10.0 Sparc alignment bug. It's actually the only thing with an order. Everything else is "not-the-top" But if anyone else wants to step up, that would be good. Nicholas ClarkThread Previous | Thread Next