lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <n...@verse.com>
Subject Re: [lucy-dev] OFFSET globals
Date Sat, 28 Apr 2012 18:28:40 GMT
On Thu, Apr 26, 2012 at 6:23 PM, Marvin Humphrey <marvin@rectangular.com> 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

Mime
View raw message