On Thu, Jan 15, 2009 at 6: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. > > 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 aren't those the type ids that we're trying to get rid of? :-) I think option 2, using strings to specify the type, is better. (should simple, single strings be enough, or do we want namespaces etc. here as well? Somehow it seems to me this is related to the recent discussion about class names, namespaces and HLLs.) kjs > > 2) Change src/pmc/object.pmc:morph() to pass the stringified name to the > PIR override instead of the INTVAL type number. > > 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 >
