--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > 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
Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass, PerlObject? __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
