On Thu, Jan 15, 2009 at 1:32 PM, Andrew Whitworth via RT <parrotbug-follo...@parrotcode.org> wrote: > Okay, I've committed a variant of my patch in r35599, but I've run into > some issues while trying to test this. The morph VTABLE interface takes > an INTVAL which represents the PMC type to morph to. This is the value > that's passed to the morph subroutine. However, there's no easy way > (that I know of) to work with these numbers from PIR. For instance, you > can't create a new PMC of that type from the number, you can't convert > that number to the stringified name of the PMC, you can find out what > the type number is of an existing class, etc.
As kj pointed out, this interface was deliberately removed from PIR. > I think there are two options to fix this: > 1) Add some opcodes such as "typename_s_i" and "typenumber_i_s" that > would convert between the string name of the PMC and the given type > number or -1 > 2) Change src/pmc/object.pmc:morph() to pass the stringified name to the > PIR override instead of the INTVAL type number. More generally, change the morph vtable to take a 'Type' instead of an it. In fact, given recent discussions about types on other threads, this should probably take a PMC, not a String, and take the same types as 'new' does. Then we remove one more point where the int number was exposed outstide of the C api. > I like the second one the best since type numbers may change internally > and we don't want people to be relying on them for other purposes. > However, then the morph vtable override in PIR will take a different > parameter list from the C version of the VTABLE interface, which might > get confusing. > > Any suggestions? > > > -- > Andrew Whitworth > a.k.a Whiteknight > > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Will "Coke" Coleda
