Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Wed, 15 Oct 2003, Jeff Clites wrote:
>> What do you mean by "new method in the class" above? > In this case, the "new method" is a named method in the class namespace > that we look up and call. We'd look it up and dispatch to it. A more low level like POV might be: newclass P1, "Foo" ... # define attributes find_method P2, P1, "NEW" # P2 is the "new" method, hash lookup here instantiate P3, P2 # P3 is a new object > The vtable method, on the other hand, would be a function in the vtable > that we'd dispatch to like any other vtable method. P3 = P1->vtable->instantiate(..) > ... It'd be a class > method, as we don't really have object methods as such. (I think, hard to > say, the terminology escapes me at the moment) PMC "classes" are basically objects obtained by the pmc_new() function. The "class" behavior is mostly fixed and done within the PMC compiler. Then we have the ParrotClass PMC which is such an "object" PMC that, when instantiated gives "Real Objects" of that class. Tha WRT terminology :) > Personally, of the two I prefer a vtable entry, as it's a lot faster. Its faster, yes. But did you consider using the OrderedHash PMC for such things. Creating is speed of (hash+array) lookup is either. So for well known methods the lookup could be just an array index lookup. > The third option is an instantiate op that has access to Deep Internal > Knowledge about classes and objects and does all sorts of Nasty Evil > Things to build the object from the class. This would probably prohibit all overloading of object construction. > find_type I4, "Foo" > new P4, I4 > instead, basically eliminating the differences between "objects" and > generic PMCs. I'm not 100% sure I want to do that, though. For now, I'd say: - generic PMCs don't have definable attributes, they are fixed - they don't have Parrot Subs as methods and - the methods they "can" are fixed, hardwired I think that for supporting Ruby or such we have to keep fences between PMCs and "real objects" very low. So it should be possible to define an Imaginary Number class that inherits from two (Perl?)Nums directly and overloads some operators without much overhead, i.e. the 2 attributes (re, im) would be kept in the 2 number PMCs. > Dan leo