Re: should GOOPS be built-in?

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Greg Harvey <Greg.Harvey@thezone.net> writes:

> It was instances that I was wondering about; as long as they
> aren't significantly larger, it's not a big deal.

The current "standard" GOOPS instances in fact take the same space as
a smob.  E.g., if you have a class with one slot the instance will
consist of one heap cell pointing to one malloc of 4 bytes.
Generally, I've tried to make things that should go fast fast by using
other expenses on things which aren't that time-critical.

And the MOP really gives the possibilities to make things unified,
flexible *and* efficient at the same time.

There are certainly things in GOOPS which can and should be made
cleaner, but it is in fact easier to do this if it has been merged.
E.g., if we choose to start using GOOPS for numerical dispatch, we
should devise specialized generic functions which can perform this
task efficiently.

Also, the current C interface "plugs in" into mechanisms of GOOPS
which are optimized for methods represented as closures
(i.e. user-level methods).  I hacked it this way first to minimize
work, so that people can have opinions about the interface.

When we feel that we are happy with the interface, we should probably
devise a more specialized class and gf representation for this task.
(And what is great about the MOP is that we'll be able to continue
 using the old representations for their tasks!)