Re: Instantiating objects
On Wed, 15 Oct 2003, Jeff Clites wrote: My brain was in PMC == class mode when I wrote what I wrote above, but now I need to rethink, since that's not a given (yet?). Not a given ever. PMCs may have a backing namespace, and that namespace may be a HLL class, but it might not. The terminology (PMC classes vs HLL classes) is definitely confusing, and unfortunate. We probably ought to have a renaming before we go live. Dan
Instantiating objects
I'm poking around in the object stuff today, to try and get at least single-inheritance objects up and running. At the moment, I'm torn between just having a new method of some sort in the class and having a vtable method on the class PMC that returns an object of that class. (get_pmc on the class returns a new object, or something of the sort) I'm open to suggestions here... Dan
Re: Instantiating objects
Dan Sugalski [EMAIL PROTECTED] wrote:
I'm poking around in the object stuff today, to try and get at least
single-inheritance objects up and running.
At the moment, I'm torn between just having a new method of some sort in
the class and having a vtable method on the class PMC that returns an
object of that class. (get_pmc on the class returns a new object, or
something of the sort)
While get_pmc is totally unused the name is probably misleading. It
accompanies set_pmc, which is basically Cassign. When I'm thinking of
get_pmc, ties and refs come to my mind (that get the PMC they are
referring to), but no new objects.
So probably a new vtable would be better. Or alternatively:
(If you didn't think of the same above :)
You put it into the find_method/callmeth scheme that we already have
(and use in parrotio.pmc) for PMCs.
That would mean: on class_init all (instantiable) PMCs get a NEW method
(maybe inherited from default.pmc) which does pmc_new()/init() on the PMC
class, which for parrotclasses does the Right Thing.
This is one extra lookup for the NEW method, but could be useful for
ultimate flexibility.
s. classes/{parrotio,default}.pmc and t/pmc/io.t for the method stuff.
Dan
leo
Re: Instantiating objects
On Oct 15, 2003, at 8:36 AM, Dan Sugalski wrote: I'm poking around in the object stuff today, to try and get at least single-inheritance objects up and running. At the moment, I'm torn between just having a new method of some sort in the class and having a vtable method on the class PMC that returns an object of that class. (get_pmc on the class returns a new object, or something of the sort) What do you mean by new method in the class above? To use the vocabulary of other languages, if you're trying to decide between a static method (a.k.a. a class method), versus a instance method on the class object, I'd say they amount to the same thing. (Either involves calling an implementation which depends on the class, and arranging for that implementation to have access to class-specific data, in the form of a class object or static class data.) Here the distinction is mostly just a matter of viewpoint--C++ has static methods, ObjC has class objects. If you're trying to decide whether the creation method should have access to a class object, then I think it should--that makes it easier to implement things such as singletons, since you have a place to hang state, such as a cache. And calling this an instance method on the class object is conceptually simpler (I would argue). Or did I totally miss your point? JEff
Re: Instantiating objects
On Wed, 15 Oct 2003, Jeff Clites wrote: On Oct 15, 2003, at 8:36 AM, Dan Sugalski wrote: I'm poking around in the object stuff today, to try and get at least single-inheritance objects up and running. At the moment, I'm torn between just having a new method of some sort in the class and having a vtable method on the class PMC that returns an object of that class. (get_pmc on the class returns a new object, or something of the sort) 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. The vtable method, on the other hand, would be a function in the vtable that we'd dispatch to like any other vtable method. 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) Personally, of the two I prefer a vtable entry, as it's a lot faster. 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. Having said that, the bytecode itself would be blissfully ignorant of any evil, since to instantiate an object for the Foo class, you'd call: getclass P1, Foo instantiate P4, P1 At least I think we would. I can see making this: 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. If you're trying to decide whether the creation method should have access to a class object This is a given, as the class object has the information we need to figure out slot allocation and whatnot. We could find it by name if we wanted to, but we might as well mandate that it be around. Dan
Re: Instantiating objects
At 03:49 PM 10/15/2003 -0400, Dan Sugalski wrote: On Wed, 15 Oct 2003, Jeff Clites wrote: On Oct 15, 2003, at 8:36 AM, Dan Sugalski wrote: I'm poking around in the object stuff today, to try and get at least single-inheritance objects up and running. At the moment, I'm torn between just having a new method of some sort in the class and having a vtable method on the class PMC that returns an object of that class. (get_pmc on the class returns a new object, or something of the sort) 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. The vtable method, on the other hand, would be a function in the vtable that we'd dispatch to like any other vtable method. 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) Personally, of the two I prefer a vtable entry, as it's a lot faster. 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. Having said that, the bytecode itself would be blissfully ignorant of any evil, since to instantiate an object for the Foo class, you'd call: getclass P1, Foo instantiate P4, P1 At least I think we would. I can see making this: 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. If you're trying to decide whether the creation method should have access to a class object This is a given, as the class object has the information we need to figure out slot allocation and whatnot. We could find it by name if we wanted to, but we might as well mandate that it be around. For some reason I'm getting the feeling that PMCs and Classes should be one and the same. Otherwise it seems we are making Parrot more complex than it needs to be. My gut feeling is that everything should be a Class, whether implemented in the C API or in bytecode, and a PMC vfun should be equivalent to a class method. That stands for PerlUnder, PerlHash, etc. as well. If we have class support, native call support and an extension API, I see no reason why we even need the concept of a PMC. -Melvin
Re: Instantiating objects
On Oct 15, 2003, at 1:48 PM, Melvin Smith wrote: At 03:49 PM 10/15/2003 -0400, Dan Sugalski wrote: On Wed, 15 Oct 2003, Jeff Clites wrote: On Oct 15, 2003, at 8:36 AM, Dan Sugalski wrote: I'm poking around in the object stuff today, to try and get at least single-inheritance objects up and running. At the moment, I'm torn between just having a new method of some sort in the class and having a vtable method on the class PMC that returns an object of that class. (get_pmc on the class returns a new object, or something of the sort) 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. The vtable method, on the other hand, would be a function in the vtable that we'd dispatch to like any other vtable method. 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) Personally, of the two I prefer a vtable entry, as it's a lot faster. ... instead, basically eliminating the differences between objects and generic PMCs. I'm not 100% sure I want to do that, though. ... For some reason I'm getting the feeling that PMCs and Classes should be one and the same. Otherwise it seems we are making Parrot more complex than it needs to be. My gut feeling is that everything should be a Class, whether implemented in the C API or in bytecode, and a PMC vfun should be equivalent to a class method. That stands for PerlUnder, PerlHash, etc. as well. If we have class support, native call support and an extension API, I see no reason why we even need the concept of a PMC. My brain was in PMC == class mode when I wrote what I wrote above, but now I need to rethink, since that's not a given (yet?). I was probably thinking that because currently the *.pmc files live in directories called classes and dynclasses (So I was thinking of PMCs as classes at the parrot implementation level--that is, if Parrot were written in C++, they'd probably be C++ classes.) So at the moment I'm a bit fuzzy on the terminology we're using--I guess there are classes and objects at the HLL level (the terminology for which may differ between HLLs), and PMC definitions (the source code) and instances (the allocated in-memory thing) at the parrot level. And I guess a fundamental design choice for parrot is that a Perl object can be treated as an object from Python code (and vice versa), although this is hard to reconcile (at least terminologically) with the Perl (Perl 5 at least) notion that strings/arrays/hashes/etc. aren't considered to be objects, but they become objects if they are blessed into a class. Hmm, I need to think this over a bit more JEff
Re: Instantiating objects
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
Re: Instantiating objects
Leopold Toetsch writes: I think that for supporting Ruby or such we have to keep fences between PMCs and real objects very low. Agreed, or have some sort of automagic transformation possible. 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. I don't think that would work. If I remember correctly, we're going to make all inheritance 'virtual', correct? Which means that inheriting from 2 number PMCs should be precisely the same as inheriting from 1 number PMC. That's okay, though, because from a design perspective, inheritance wouldn't be the way to go about that kind of problem anyway :-) Luke Dan leo
