On Tuesday 02 March 2010 at 17:03, Andrew Whitworth wrote: > > Move the code that performs the lookup of the method out of Object into > > src/oo.c (or possibly src/oo/class.c) and, all of a sudden, it's not > > violating the Class PMC's encapsulation any more. > I don't see how that helps at all. The code to access the internals of > Class would still not be in class.pmc, which means that Class *isn't* > encapsulated,
The code to access the internals of Class isn't all in class.pmc *now*. That ship has not only sailed, but the conquistadores burned it years ago. > and we can never use a type as a metaobject or method > storehouse that isn't a Class PMC or an item that is painstakingly > isomorphic with it. Sure we can. The VTABLE find_method *already* finds a method on every PMC you call it on. If a PMC doesn't do anything sane for that call, whoever implemented that PMC did something silly. > Instead of providing a single interface function > and delegating the search out to the objects that implement the MRO, > we're still using code external to Class to walk the MRO in a way that > only supports Class. Read src/oo.c sometime. Code external to Class does many, many things related to Class. (Read every PMC sometime. Code external to almost every PMC does things related to those PMCs. Our encapsulation problem in Parrot is *too much* encapsulation in PMCs, sometimes -- look at the mess between NameSpace and Class.) > Multiply entities? Asking Class to manage it's own method lookup as > opposed to creating some entirely new mechanism to perform the lookup? Class manages its own method lookup just fine, modulo the utterly false distinction between method storage between intrinsic PMCs and PIR-defined classes. > First, I would love to see an example of a compiler providing it's own > Class and it's own Object. I'm not even certain how that would work > internally. Both the newclass and subclass opcodes create a > non-HLL-mapped enum_class_Class PMC. As Jonathan said, look at Rakudo. Then imagine a JavaScript or Self or Io or Rebol implementation that doesn't use class-based OO, and for which strewing the assumption throughout Parrot that you can look up class methods with the find_class_method VTABLE leaves us with little hope of getting things right. The moment you make all method invocation immediately pull the instance's class and run find_method or whatever your new VTABLE is on *that*, you've completely ruined the possibility of prototype OO working at the VM level. A new metaclass is an instance of the Class PMC, and you create new objects of that metaclass through the use of that metaclass. > I concede that it is strictly possible for us to create our own > metaobject type and use that with the new opcode to instantiate > instances of that type, There's no need of a new opcode to do so. > but we would lose a lot of the infrastructural > support that Parrot provides to Class. For instance, if the class > wasn't registered and a VTABLE wasn't created for the type, That's a nonsensical situation. > we would > not be able to use Parrot_pmc_new(), and would never be able to HLL > map our type for core to use. Maybe you could hack this support > together IF you wrote your metaobject in C instead of PIR and > completely violated encapsulation of the Parrot API, but I would > hardly advertise this as an alternative because it would be so > hobbled. I cannot imagine an implementation of a programming language written so incompetently that this would be an issue. > There are two ways to look up the method in an arbitrary metaobject: > Either call an API function, or have a priori knowledge of the > object's internals. As a counter-example which would be impossible > using the current Class interface, consider something akin to Perl5's > AUTOLOADER. AUTOLOADER cannot produce a hash of available methods on > demand, because those methods are not necessarily loaded into the VM > until explicitly searched for by name. Don't get me started on the brokeness of most Perl 5 code that does not handle AUTOLOAD appropriately. It's entirely possible to write code that uses AUTOLOAD and manages to respond to introspection correctly; it's almost trivial to do so, yet far too few Perl 5 programmers know how to do so. (Even so, you can accomplish the goal of making AUTOLOAD feasable--supporting Perl 5 behavior appropriately--through appropriate use of the find_method VTABLE without unnecessary new VTABLE entries. Parrot borrowed too many bad ideas from Perl 5, but it didn't get this one wrong.) > If space isn't the option, then I have no idea what your objection is. Adding unnecessary and questionable features is a mistake. > Yes, the way default does method lookup now is broken. Instead I > suggest we give PMCProxy an interface function and delegate the lookup > to it. PMCProxy knows what methods are available because it's going to > contain them all. default.pmc should throw a not found exception when > find_method is called on it. You break the ability to define methods on Hash by doing so! 49 out of 83 PMCs have METHODs, and only three of those 49 are Class, PMCProxy, and Object. > > The same way we look up methods in Classes now. A Class has a Hash which > > contain methods indexed by name. > Again, AUTOLOADER. A complete hash might not be available. In any > case, how do we get that hash? Direct attribute access (which limits > implementation) or a VTABLE? See the can VTABLE entry. Direct hash access has the same flaw as most Perl 5 code which uses AUTOLOAD. If you haven't read "The Art of the Metaobject Protocol" yet, I recommend it. -- c _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
