Front page | perl.perl5.porters |
Postings from September 2011
On Wed, Sep 14, 2011 at 01:55:15PM +0100, Zefram wrote: > You're thinking of "object" in the OO sense. I meant it in the looser > sense, of anything that the language can manipulate by first-class > mechanisms. It's an object in the same sense in which an (unblessed) > array is an object. We could well call it merely a "package". It would > probably end up implemented as an svtype, SVt_PVPK. On boy, is that going to break any XS code that processes hashes, identifies hashes as SvTYPE(sv) == SVt_PVHV, and is used by any other code that passes in stashes, knowing that stashes are just hashes. It is an ingrained weakness of the current implementation that for the past 15 years the "official" way to ask "is it a hash?" or "is it an array?" (etc) in C is an explicit equality check with a single type. I'm still thinking that having vtables for hashes (and arrays)(as a first step) is a way out of this mess. SvTYPE() remains SVt_PVAV or SVt_PVHV, but the core APIs know how to indirect through the vtable. (And possibly for space reasons, know what the "traditional" default-behaviour vtable is, to avoid storing it) This also opens up the ability to have alternative storage representations, without existing XS code knowing anything about it. (and being able to provide such implementations as CPAN modules) Nicholas ClarkThread Previous | Thread Next