Path: utzoo!news-server.csri.toronto.edu!wotan.ai.toronto.edu!kramer
Newsgroups: comp.lang.clos
From: kramer@ai.toronto.edu ("Bryan M. Kramer")
Subject: Beefs about CLOS
Message-ID: <91Mar13.134622est.133188@wotan.ai.toronto.edu>
Organization: Department of Computer Science, University of Toronto
Date: 13 Mar 91 18:46:39 GMT
Lines: 62

I have just begun using CLOS after having had considerable
experience in LOOPS and C++. There are two things about the
language I find really annoying. I don't imagine that
they can change, but I felt like getting them off my
chest. Since I'm fairly new to CLOS, maybe I'm misinterpreting
the spec.

1) Congruent lambda lists for generic functions. The
main problem with this is that it seems to go against
modularity in that the designer of a class has to make
sure that no method names conflict with method names for
other classes. For example, suppose one is working in
an environment that contains graphical interface package
with a class hierarchy for graphical objects that has
a method called LAYOUT. Suppose now, that you are writing
a system for chip design and decide the best name for
a certain method here is also LAYOUT. Suddenly you have
a name conflict that you wouldn't have had in LOOPS or
C++.

A second problem with congruency arises when one would 
like to write two different methods to perform the same
function ... here one would like the same method name
but different lambda lists. For example, a graph
manager object might have two PLOT methods, one which
accepts an array of x-y pairs and another which accepts
a list of pairs ((x1 y1) (x2 y2) ...) as an argument.

It also seems common to need to add parameters as one
specializes methods ... this is practically a very useful
capability although I can see theoretical arguments against
it.

Note that &optional or &keyword parameters don't fit the
bill because one cannot specialize methods based on these
parameters.

2) Custom arguments to INITIALIZE methods. I find that frequently
that the values I would like to pass to make-instance to
initialize an object are not values that I would like to
store in slots. An artificial example here is a system that
stores locations in polar coordinates but that is naturally
initialized by Cartesian coordinates. Where I would want
to write
[a]    (make-instance 'position :x x :y y)
I have to write
[b]    (let ((new (make-instance 'position)))
       (setup new x y)
       new
       )
The biggest problem is that I run into 1) above, i.e.
lambda list congruency. I have to invent a new name for
SETUP for every class for which this is necessary. Being
allowed 2) without 1) would still be a problem because
it would be nice to also allow the initialize method to
use cartesian coordinates if necessary.



 Bryan M. Kramer	- 416-978-7330 -
 Department of Computer Science, University of Toronto
 Toronto, ON      M5S 1A4