Foor for thought... There currently is a 'morph' vtable entry, which I believe is intended to morph from one vtable type to another. I think it'd be better to implement this function properly than to use macros (talk to Robert ;), especially considering that certain vtables might have special morphing requirements, such as setting PMC_is_buffer_ptr_FLAG.
Of course, morph seems to be unimplemented, and my attempt at implementing it ran into a problem, which I brought up here: http:[EMAIL PROTECTED]/msg09317.html There are two problems: a) morph will break horribly when we deal with tied variables, since it will have to reimplement *every* PMC method to avoid any morphing. b) Since it's possible that dest == src, we need to make a copy of our data (be it a buffer ptr, or regular number) on the local stack, call morph() to morph the PMC and initialize data, and then set the new value. This pattern is currently utilized in the string PMC methods, but not with the number-related methods. So in conconclusion, while I don't have any reservations about your patch, I do have a preference that it be done differently. :) Mike Lambert
