Re: Syntatic sugar and identifier permissivity

[Craig Brozefsky <craig at red-bean dot com>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> Craig, 
> 
> > The reason is that in Perl, a method is just a function scoped within
> > a class 
> 
> even in CLOS a method is simply a message within a package scope.

I think your mistaking one possible use of generic functions as being
the essence of them.

There is quite a difference between Perl and CLOS on this matter.  In
Perl, Packages and Classes are the same, since an object is "a
reference that happens to know which class it is" and a class is
"simply a Package that happens provide methods to eal with objct
references" and a method is "a subroutine that expects an object
reference of a class name as it's first argument".

In CLOS, generic functions are named by a symbol which is in a
Package.  Methods are attached to this generic function and are not
limited to the scope of the package they are defined in.  So, unlike
Perl, classes are not "simply packages", and methods are not scoped to
classes at all. You can list all methods that specialize on a given
class using the MOP, but this is done by going thru all of the generic
functions and looking at their methods' specializers, not by looking
at the scope of their name.

> If a language does or does not support MD doesn't matter.  But it
> *is* important to divide a software system into groups of classes.

I'll by that for a dollar.

> If you use P->m(s ...) or (P:m s ...) or (m P s) is only a matter
> of style. I prefer the (<method> <package> <specializers> ...)
> syntax but (P:m s ..) as in CLOS is also reasonable.

That is not CLOS at all tho.  You never name methods, you name generic
functions.  So it would be (P::gf s ...)  And then the method dispatch
mechanism would go thru gf's methods and build the applicable method
list and then apply them.

Does GOOPS presently support or plan on supporting user definable
method combinations, or :around, or :before, or :after combinations?
How would you handle it here?  How do you handle (call-next-method) if
what I'm refering to is a method, not a generic function?

> The nice thing with (m P s) is that:
> a) no external overrides are possible because the module context
>    is now a specializer,
> b) for the same reason we can drop the global variable *the-module*;
>    m's module context is passed as the argument P.

Either your forgetting about generic functions, or there is something
going on in GOOPs which I don't know about which throws them out
entirely.

How are you handling methods defined in module A, but which
specialize on a class in module B.  Example of this would be a
(serialize x) function, or a (print x) function?

How are :around and other method combinations handled if the some
applicable methods specialize on a superclass, or even the second or
third argument to the function?  How do we resolve which one is
called?

Namespace management and method dispatch are different, ESPECIALLY
with multi-dispath, so why are you mashing them together?

If the latter is the case, then I can't really add much more to the
thread, because GOOPS would not be something I planned on actively
contributing too and using then.  It is indeed your code to write, and
not mine, but I can't help but wonder why you are endeavoring to so
completely gut the model that GOOPS was supposedly built upon and
replace it with a cheap copy of other, lamer OO systems.

-- 
Craig Brozefsky                      <craig@red-bean.com>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli