unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: guile-user <guile-user@gnu.org>, Neil Jerram <neil@ossau.uklinux.net>
Subject: GOOPS and Code Complexity
Date: Tue, 09 May 2006 11:43:20 +0200	[thread overview]
Message-ID: <87fyjjr0sn.fsf_-_@laas.fr> (raw)
In-Reply-To: <66e540fe0605090130r70be830bo40a21ae71b043b5b@mail.gmail.com> (Mikael Djurfeldt's message of "Tue, 9 May 2006 10:30:10 +0200")

Hi,

"Mikael Djurfeldt" <mdjurfeldt@gmail.com> writes:

> On 5/9/06, Ludovic Courtès <ludovic.courtes@laas.fr> 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.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


      reply	other threads:[~2006-05-09  9:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-04 19:13 [goops] adding a number class with generic methods Marco Maggi
2006-05-04 19:26 ` Mikael Djurfeldt
2006-05-06 23:07   ` Neil Jerram
2006-05-07  9:37     ` Mikael Djurfeldt
2006-05-07 11:45       ` Neil Jerram
2006-05-09  7:56       ` Ludovic Courtès
2006-05-09  8:30         ` Mikael Djurfeldt
2006-05-09  9:43           ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fyjjr0sn.fsf_-_@laas.fr \
    --to=ludovic.courtes@laas.fr \
    --cc=guile-user@gnu.org \
    --cc=neil@ossau.uklinux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).