GOOPS and Code Complexity

[Ludovic Courtès]

Hi,

"Mikael Djurfeldt" <address@hidden> writes:

> On 5/9/06, Ludovic Courtès <address@hidden> wrote:
>> And thus the first `define-method' creates a new, empty, generic
>> function.  That makes it sometimes quite tricky to spread method
>> definitions all over the place (e.g., see G-Wrap...).
>
> Could you elaborate on that?  In what way does GOOPS/module system
> make this tricky, and how do you envision a better design?

Oh, I do not mean that GOOPS and Guile's module system make GOOPS hard
to use --- and I'd be unable to envision a better design.  I think
they're both good at their job.

Rather, my opinion is that CLOS-like systems are so flexible that it can
make it quite hard to understand the structure of a piece of code,
specifically when method definitions are spread across different
modules.

This is what happens in the GOOPS-based G-Wrap.  A set of classes and
generics are defined in some top-level module.  Then, there are various
modules that add two-line methods to these generics.  Since there's a
relatively deep class hierarchy, understanding what the control flow may
be can be quite hard, especially in the presence of `next-method' calls
("vertical code reuse", which I find problematic --- but this is not
CLOS-specific).  Interestingly, in G-Wrap, some modules specialize
methods to classes that are not exported themselves.  Nothing wrong with
that, but again, it doesn't help the reader.

Also, the fact that method dispatching takes all arguments into account,
as well as the number of arguments, is one of CLOS' strength compared to
static OO languages like Java/C++.  But it also makes it harder to guess
what code will be executed by just looking at a given method call.

As a method-overloading-module author, one must make sure to:

  1. Not export the binding in question (as shown with this thread);

  2. Import the module that actually defines the generic;

  3. Correctly spell the generic's name.

Of course, these are all necessary for ordinary procedures as well.  But
in the case of GOOPS methods, these can yield harder-to-find errors
(see, e.g.,
http://lists.nongnu.org/archive/html/g-wrap-dev/2005-09/msg00000.html ).

Furthermore, CLOS-like systems introduce a new class of side-effects
that has to be taken into account by the user.  Usually, the only
side-effect induced by using a module is that it modifies the user's
name space.

When GOOPS method definitions are spread across modules, one must be
aware that using a module means more than just adding bindings to their
name space.  For instance, one may have to use a module even if none of
the bindings it exports is of interest, just because that module adds
methods to various previously-defined generics.  Understanding that kind
of relationship among modules is not trivial when reading a
harmless-looking list of `use-module' clauses, IMO.

Another way to express all that it that CLOS is very name-centric.  This
makes a significant difference compared to the Scheme philosophy where
names (top-level bindings) can often be avoided by passing
procedures/closures around.

> Rather, I think the points where it can be criticized is that some
> things are a bit "too automatic" and there should be better and more
> error messages in some cases.

Right, it is true that it's a bit "too automatic".  OTOH, automatic
features like automatically creating when the first `define-method' for
a given name is encountered are quite handy.

As for error messages, I'm not sure they could really be improved.  In
fact, issues like those I mentioned above are "normal", i.e., they are
not GOOPS' nor the module system's fault: rather, these are traps users
should pay attention to.  ;-)

> Of course, one may feel that the fact that methods can "spread"
> through the generic function in a rather arbitrary manner across
> module borders is a problem.  For those who want a more restricted
> access to methods, there is the possibility to use extended
> generics. This is explained in NEWS, I think.

I couldn't find information about it.  Do you have more specific
pointers?

In fact, I had been very enthusiast about CLOS in general and GOOPS in
particular for some time.  Now, I no longer find it so cool, notably
because of the readability issues I mentioned earlier.  I also tend to
agree with the arguments in http://paulgraham.com/noop.html and related
pages.

Thanks,
Ludovic.