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
