On Thu, Apr 26, 2012 at 6:23 PM, Marvin Humphrey <[email protected]> wrote: > If that were _PERL, we would eliminate Host_callback() indirection layer and > flesh out the function body with raw XS:
+1. I like that it removes a layer of indirection, and makes it clearer what the function does. And I might be overplanning, but I think there are cases where it might be nice to try to bridge between to host languages, Host language specific naming would allow for this. >> 7) It must be possible to dynamically subclass a core class at runtime. > > +1 > > You might say "non-final public class", since we support "final" classes. > (InStream and OutStream are both final.) Yes, more correct. But what I'd like to move towards is a policy of "if you can grab hold of it, you can subclass it", with the final or non-public classes being static or otherwise opaque in the object file. This doesn't need to be absolute, and convention will still play a role, but reduced visibility equals reduced temptation. >> 7) a. Dynamically created subclasses should be indistinguishable from >> and interchangeable with core classes. > > I prefer your other formulation. I don't think the inability to get at > pure-host-language subclasses from C poses a major impediment. Perhaps we need to distinguish between compiled extensions and scripted extensions. Classes in compiled extensions are interchangeable with core classes; classes created by a scripting language might not need to be. Simplicity has advantages, though, and it would be nice if once they are registered that one can't tell the difference. Would be even nicer if the pathways to registration were the same for both. Like you, I'm not worried about Core->Script->Compiled extensions. But I do want to make sure that Core->Compiled->Script hierarchies works identically to Core->Script. And certainly we want Core->Script->Script to work within the same host language. Do we care about Core->ScriptA->ScriptB: probably not, although I maybe if ScriptA was something embedded like Lua. But I see no harm in aiming for this capability as a polygot point of pride. >> Before thinking about approaches, there is at least one more potential >> constraint questions that concerns me: How important is the ability >> to for objects to be able to have a "private" VTable? > > I interpret your phrase '"private" VTable' as meaning "a dedicated VTable > singleton for each subclass, distinct from the VTable singleton belonging to > the parent class" -- in which case the answer is that per-class VTable > singletons are mandatory. I guess I was fumbling with terminology again. In a class-based OO system, every object is in a class, and every instance of that class has the same methods. In an instance-based system, it's possible for one instance to change its behaviour without formally creating a new class. Currently, it looks like it's possible for a Clownfish object to create a per-instance copy of the registered per-class VTable using VTable_singleton. Within Clownfish this copying is as part of the process of creating a subclass, but I don't see any technical reasons that an object couldn't create this copy, modify it, use it, and never register it. Multiple objects could even share this "private" and unregistered VTable, or others could copy and modify it creating an ad-hoc prototype system independent of the official class hierarchy. I'm not advocating for this, but wondered if this was a valuable capability that should be preserved or just a spandrel. What I will be advocating for is a window of malleability before the classes are registered. I'm with you regarding immutability once a class is "visible", but I'd like the host language to have a shot at things before the core classes are declared visible. I also want to make sure we preserve the current unadvertised ability to override the core methods with compiled "overlay" extensions using LD_PRELOAD. But this is a secret I'm waiting to spring on you at some later point when have a better feel for the whole situation. > Even if you don't override any methods, the VTable > stores other metadata, like the class name. > (Which is why "VTable" should be > renamed to "MetaClass" -- it's not just an array of function pointers any > more.) +0. I see your logic, but I'm not a fan of "MetaClass" as a name. VTable might be technically inaccurate, but it sets up the right expectations. > Thanks for starting up a requirements list, as recommended in that > Joshua Bloch presentation. Now I'm worried that you read every link I send you in full, and that if I were to accidentally send the wrong long thing we could lose you for weeks! I'll try to make sure to aim for high quality at least. :) --nate
