RE: Objects, finally (try 1)

[Dan Sugalski]

At 9:51 AM -0800 1/14/03, Jonathan Sillito wrote:

Dan,

Below are some questions about this ...

And now some answers. :)

 > -----Original Message-----

 From: Dan Sugalski [mailto:[EMAIL PROTECTED]]

[snip]

 Objects, as far as I see it, have the following properties:

 1) They have runtime-assignable properties

Terminology question: what is the difference between a property and an
attribute? Perhaps the answer could go in the glossary.

A property is a runtime assignable name/value pair that you stick on a variable or value. An attribute is a named variable that all objects of a particular class have.

Properties can come and go at runtime, but attributes are fixed. (I think you could also consider attributes "instance variables", but I'm a bit OO fuzzy so I'm not sure that's entirely right)

 > #3 Since each class has a PMC type, we just need to associate the PMC

   type with the data a class needs. Also pretty much no big deal, and
   something we already have facilities for.

So, while there may be exceptions, generally all classes will be instances
of the Class PMC, true?

Generally, yes.

 > The call/jmpmeth opcodes either make a returnable or non-returnable

 method call. They fetch the function pointer from the object PMC and
 either dispatch to it or save the current state and jsr to it. Note
 that you can't jmpmeth into a C-implemented method, so no tail
 calling into those without some wrapper opcodes. The registers still
 need to be set up appropriately, just like with a regular sub call.

So the call opcode takes a method name or offset and calls a vtable method
to find the method and then invokes it?

Yep.

 > The find_method vtable entry should die, and be replaced with a plain

 method entry. This should return either the address of the start of
 the method's bytecode, or NULL. The NULL return is for those cases
 where the method actually executed via native code, and thus doesn't
 have to go anywhere. If an address is returned it's expected that the
 engine will immediately dispatch to that spot, obeying parrot's
 calling conventions.

Not sure what this means, does it mean that there is a method named
"find_method" accessed something like

  call Px, Py, "find_method"

which I can then call to find the method or am I off?

You're off. It'll be something like:

   callmethod Px, "method_name"

or

   jmpmethod Px, "method_name"

 > The structures:

 *) Attr PMCs have an array off their data pointer.

 *) Classes are variants of Attr PMCs. They have the following
   guaranteed attributes in slots:

     0) Hash with class name to attribute offset

I am not sure what this means, Don't we already have the class and it's
attributes if we are accessing these slots?

Well...

The problem is finding which slot to access, a problem that's compounded by multiple inheritance.

Let's say, for example, that you have a class A, which inherits from B and C. Let's also say that each class has 10 attributes, and you have a fixed-width mail reading font. The inheritance diagram then looks like:


C B
\ /
|
A

Since the attributes are an array, it looks like:

CCCCCCCCCCBBBBBBBBBBAAAAAAAAAA
012345678901234567890123456789

We make a method call and it gets resolved to be one we inherited from B. Now, how does B know which slots in the object holds its attributes? In a single-inheritance case, it could assume that since it has no parents it can start at slot 0, but that doesn't work here--C is first. So what B needs to do is query the object to find out where the attributes for class B start in the attribute array, and to do that it looks in the hash stored in the object's class attributes that maps class names to starting offsets. From there B can figure out what slot to look in, since class attributes are contiguous, and thus there only needs to be a single lookup.

Single inheritance makes all this resolvable at compile time, which would be so much nicer. Alas, no joy for us there.

 >     1) Hash with attribute name to attribute offset (relative to the

        offset found from the hash in slot 0, generally known at
        compile time, but introspection is nice)
     2) Integer number of attributes this class has
     3) Notification array

Do we store ptrs to parent classes in one of these slots? Also Can I access
slots like:

  set Px, Py[1]    # store the name to offset hash in Px

No the parent's gotten to via the vtable, and yes you can.

So to sum up we need the following pmc's:

  pmclass Ref {
    data is a pointer to an object
  }

  pmclass Attr {
    data is an array of attributes
  }

  pmclass Class extends Attr {
  }

  pmclass Object {
    this was not explained, but I guess it at least
    has a reference to a Class and field data ???
  }

Does that cover it?

I'd say so, yep.
--
                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk