Re: [j-devel] No CLOS :metaclass option support

[Alessio S. <ale...@gm...>]

On Mon, Jan 19, 2009 at 5:42 PM, Chun Tian (binghe)
<bin...@gm...> wrote:
>
> On 2009-1-19, at 22:41, Alessio Stalla wrote:
>
>> I'm not very convinced about this. I think some sort of Java
>> integration can provide some benefits (i.e. as I said tight
>> integration between CLOS and the Java object system). I'm not saying
>> that ABCL's CLOS should be written entirely/mostly in Java, but the
>> lower-level building blocks (let's say the minimal object system
>> implementation needed to bootstrap CLOS, where it makes sense) could
>> imho be written in Java.
>
> Below is just a brain-storm ...
>
> The standard CLOS class hierarchy is a bit like this:
>
> T
> |- STANDARD-OBJECT
> |  |- STANDARD-CLASS (classes served as other class' :metaclass)
> |  `- other classes (defined by DEFCLASS with superclass not under
> STANDARD-CLASS)
> |
> |- STRUCTURE-OBJECT (objects defined by DEFSTRUCT)
> |
> |- NUMBER
> |- SYMBOL
> |- ARRAY
> |- ...
>
> But since ABCL is a pure-java CL implementation, I think we can easily add a
> new class called "JAVA-OBJECT":
>
> T
> |- STANDARD-OBJECT
> |- STRUCTURE-OBJECT
> |- ...
> |- JAVA-OBJECT
>
> JAVA-OBJECT and its every subclasses should have a fixed metaclass
> "JAVA-CLASS", I don't know if there can be a MOP to extend it by defining
> subclass of JAVA-CLASS, but we can just leave it for the future.
>
> The JAVA-OBJECT class is just mapped to Java's Object class, all other Java
> class should be its subclass. The whole JAVA-OBEJCT hierarchy and language
> mapping should be obviously written mainly in Java, and it can be integrated
> into PCL, if we really do it.
>
> Is that a good design?
>

Well... that's more or less the current design in the scripting branch
so, I hope it's good enough ;)
As for integrating them with PCL, I don't know PCL so I can't estimate
how hard would it be, but probably not very hard since JAVA-OBJECT -
JAVA-CLASS are actually pretty simple and separate from the rest (as
you have correctly noted).
Of course, a well functioning CLOS + MOP is more important than Java
integration which is just an extra... but if such an integration is
easy to achieve with PCL, I'll be happy to contribute it.

Ale