On Wed, 18 Feb 2004, Dan Sugalski wrote: > Just to let everyone know, if there aren't any comments on the scheme > in PDD 15, I'm going to implement it as-is and be done with it, at > least for now. This would be a good time to speak up--can't guarantee > that I'll put the changes in for this rev, but I certainly can't > think about it if I don't have them.
I think you're doing a great job here. This is a TOUGH problem and you've really boiled it down into a clear and simple spec. I do have a few comments/questions: You said in an earlier post that python won't be able to talk to objects with attributes without a syntax change. I don't think a syntax change will be required -- we just need a wrapper class. But it would be *SO* much nicer if properties and attributes were mutually exclusive, and the same interface worked for both. I thought that was the point of having vtables. I'm all for having both, but the implemenation should be encapsulated. I think it's a big mistake to create two separate interfaces. For callmeth, callmethcc, and tailcallmeth... I can understand the versions with the string... It looks up the method off of the PMC in P2, right? But what good is the version without the string? How are they different from the normal function invocation ops? Again, I'm wary of the separate interface for object stuff. For these two: """ addattr Px, Sy, Sz Add attribute Sy, with a fully-qualified name Sz, to class Px. This will add the attribute slot to all objects of class Px and children of class Px, with a default value of Null removeattr Px, Sy, Sz Remove the attribute Sy (fully qualified name Sz) from class Px, all objects of class Px, and all objects of a child of class Px. """ Shouldn't there be correspdonding vtable methods for these? And shouldn't those methods get to decide how/if the instances are affected? There were two parts of the spec where I just plain didn't understand the language. First: """ The catalog metadata for objects is considered to be attributes on the class, so to get the offset for a class for an object, you fetch the object's class then look up the offset attribute from it. (The class attributes are detailed later) This is safe in general, since the only code reasonably querying a class' attribute list is the class code itself, and if a class doesn't know whether it's a ParrotClass-style class or not you've got bigger problems. """ Does this "catalog" have something to do with mapping strings to the appropriate position in the attribute array? "catalog" isn't mentioned anywhere else in the file, and "metadata" only shows up for the instantiate op... So I really don't get this at all. The reason I thought a catalog might map strings to ints is because there doesn't seem to be a vtable method for looking attributes up by string. What's the mechanism for making this happen? I also don't understand this opcode: classoffset Ix, Py, Sz Returns the offset of the first attribute for class Sz in object Py. What do you do with it once you have it? Is it for when a class has two parents with attribute "X" and I want to find the one for one superclass or the other? That sounds useful, but it's just my guess at what you're talking about. :) I don't mean to be so grouchy, but you said to speak now or forever hold my peace, so... This is it. I'll do my best to make pirate work with whatever you come up with, but I'll say this one more time: Encapsulation is our friend! Please don't complicate the system with duplicate interfaces. Sincerely, Michal J Wallace Sabren Enterprises, Inc. ------------------------------------- contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -------------------------------------
