Re: goops - accessors, methods and generics

[Mark H Weaver]

Hi David,

David Pirotte <address@hidden> writes:
> no, what needlessly complicates things is the unfortunate decision of guilers 
> to
> mix goops with the module system:  you do not want any [by far inferior] 
> module
> system to interfere with clos/goops. [...]
[...]
> if at least guile designers and goops implementors would have provided a 
> 'switch'
> so that we could ask that any and all goops related stuff being in a single 
> name
> space available 'anywhere' at all time [such as guile core functionality is],

No, guile core functionality is *not* in a single name space.  It is in
the (guile) module.

There are several problems with your proposal.  First of all, there's no
syntactic distinction between generic function calls and ordinary
procedure calls.  For that matter, in Scheme the operator position of a
procedure call is evaluated in the same way as any other expression.

So, in the context of Scheme, what you're suggesting essentially boils
down to this: every *variable* lookup would have to first look in your
"single name space" before looking anywhere else.

But let's set this (very serious) problem aside for the moment.
I want to explain the reason why I believe a "single name space" is
fundamentally a bad idea, even if generic function calls *could* be
syntactically distinguished.

Suppose Bob uses GOOPS to write a component for drawing things on a text
display using curses.  He defines a 'draw' generic function, and add
several methods to it, including methods to render all of the standard
Scheme types such as lists, vectors, and strings.

Now suppose that Alice uses GOOPS to write a component that also defines
a 'draw' generic function, but with very different semantics.  Alice
adds her own methods to 'draw' the standard Scheme types.

The module system allows these two components to coexist in the same
system without those two 'draw' generic functions from interfering with
each other.  This in turn allows hackers to use short names such as
"draw", "ref", "x", etc, without fear of unintended conflicts.

What's worse: under your proposal, if conflicts arose between modules,
there's no easy way to fix it.  You'd have to rename the generic
functions in one of the components to avoid the conflict.  In practice,
people experienced with such a system would eventually learn that they
must pick long variable names and cross their fingers, just as people
did in the bad old days of dynamically-scoped variables.

So that's the argument in favor of the module system.  What's the
argument on the other side?  Apparently, it's that you find it
inconvenient to define your interfaces (generic functions) in a separate
module and to import that module in all of your other modules.

To my mind, the arguments in favor of the module system are *far* more
compelling than those of the other side.

I'm sorry that you chose to characterize our position as "religion".
Personally, I found that very disrespectful.

     Mark