On Oct-23, Dan Sugalski wrote: > At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote: > >>Possible (feature/architectural) goals for 0.0.9 > >>------------------------------------------------ > >>* PMC cleanup > >> - Leo did a huge amount of work on this, but there are a few things > >> left: > >> - array.pmc still autocreates something called "PerlUndef" > > > > > >This is the way it worked earlier too. The problem is (and was) that > >extending an array just makes room for new PMCs. Allocating all PMCs > >during extension is not an option (IMHO) this would render sparse > >arrays to an noop and would be expensive, if these PMCs remain > >unused. Now, setting the value of an array cell is done by a vtable > >method like set_integer_native, which requires an PMC to be there, > >which happens to be a PerlUndef, changing its vtable immediately to > >the desired type. > > It's OK for the array.pmc class to not care about sparseness. I'm > fine with us later on adding a sparsearray.pmc. > > It'd probably be a good idea for us to have a generic undef.pmc for > undefined usage. Dunno if there'll ever be any reason for it to > behave differently than perlundef, but it might. For now, perlundef > can just subclass undef. (Which means, I suppose, that we just rename > perlundef to undef and make a few changes in places that need it) > --
Yes, that's what I was saying. Sorry the comment was vague -- all I meant was that general Parrot PMCs should not be creating Perl-specific PMCs. I agree completely with Dan's solution. Is there anything Perl-specific about the current PerlUndef? If not, then just renaming it to Undef seems best.
