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




Reply via email to