[Openmcl-devel] Re: MOP support and porting UncommonSQL

[Gary Byers]

On Mon, 17 Mar 2003, Ram Krishnan wrote:

> Hello,
>
> Just a follow on to my earlier email after having spent a little time
> looking at the code for the openmcl CLOS implementation. I realize now
> I should have asked a different question, which is whether anyone on
> this list is working on a MOP implementation for openmcl. I realize
> this is one of the TODO items listed on the openmcl web site but if
> anyone has started on it, I'd be interested in helping.
>
> Regards,
>
> -ram
>

I know that someone has done a (mostly if not entirely) MOP-compliant
ENSURE-CLASS for MCL (and a modified DEFCLASS that expands into code
that calls it and some other related functionality); it's designed to
be a patch loaded on top of MCL's CLOS implementation, but I think
that it'd be fairly easy to drop it in to OpenMCL.

There are lot of areas of missing MOP functionality that revolve
around the fact that slot definition objects aren't objects in
OpenMCL.  It -seems- like it'd be possible to make that change
relatively independently of other things, though of course there
are circular bootstrapping issues.

As I said earlier, the implementation of SLOT-VALUE devolves into a
linear search (even in cases where the class name,
"standard-class-ness" of that class, and slot name are known at
compile time.)  I think that those cases are common enough that if
they were handled more reasonably, the general case could absorb
whatever performance hit the introduction of SLOT-VALUE-USING-CLASS
might incur.

There may be other things that would qualify as important first
steps towards (at least more of) the MOP, but these two come to
mind. If anyone's interested in working on those things, it'd
certainly be appreciated and I'd be glad to help in whatever way
I can.

One thing to consider is that the only CLOS classes that OpenMCL
really uses are streams and conditions.  The type system and
printer depend on parts of CLOS as well, but I think that
streams and conditions are the only standard classes that are
subclassed or instantiated.  Temporarily replacing CLOS
streams and condition objects with less-flexible built-in/structure
based versions would make it easier to break more of CLOS while
working on it, and that could be an important consideration.



_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel