An objection some people seem to have about CLOS is the
problem of code organization. Which file do you put
a method definition in? In languages like C++ and Python
you are forced to put the methods INSIDE the class definition.
Thus you do not have any freedom in code organization.
In CLOS, methods do not belong to classes except conceptually
at a very high level, and then only excluding multi-methods.
Should you group defmethods by class, or by generic function?
Or should you simply group defmethods together which are
semantically related?
In my own opinion, it seems ok to use some mixture of
these coding styles, whatever makes sense at the time.
But people who read my code sometimes complain that
they never know where to find the appropriate defmethod.
Are there guidelines for code orginization which seem
to make code more readable? Is "readable" for the expert
different from "readable" to the beginner?
On Tue, 13 Jul 2004 07:18:00 +0200, Jim Newton <·····@rdrop.com> wrote:
> Should you group defmethods by class, or by generic function? Or
> should you simply group defmethods together which are semantically
> related?
>
> In my own opinion, it seems ok to use some mixture of these coding
> styles, whatever makes sense at the time.
I also think that this is OK. FWIW, I try to follow these
"guidelines" of my own:
1. If I write methods which directly alter the behaviour of the
objects (like :BEFORE, :AFTER, or :AROUND methods for
INITIALIZE-INSTANCE or SLOT-UNBOUND) I put them in the same file
where the DEFCLASS is.
2. Sometimes methods obviously "belong" to one class (if they only
specialize on one argument) so I try to put them near the class
definition. (One could argue that this is also implicitely done by
DEFCLASS when accessors are defined.)
3. For more complicated methods I think it's reasonable to group them
by generic function.
> But people who read my code sometimes complain that they never know
> where to find the appropriate defmethod.
The IDE should help them to find it.
> Are there guidelines for code orginization which seem to make code
> more readable? Is "readable" for the expert different from
> "readable" to the beginner?
Good question... :)
I haven't thought about this thoroughly but I tend to think that good,
clean code written by experts will be readable for a beginner
(provided he knows all language constructs involved).
Cheers,
Edi.
--
"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
I have somewhat the same issue with globals. Should they all go at the
top, or should they be scattered around the file with the functions
that they belong to?
My personal feeling is to scatter definitions and thuis keep them
together with what they logically belong to, trusting the development
tools to help you. I do not know how nicely SLIME or ELI plays with
the different instances of defmethods (etags certainly has issues) but
with globals (defvar et al) that will work very well.
In a larger project it will be pretty difficult to know in advance
where things are, so good cross-referencing will probably always beat
any kind of all-foo-are-in-the-top-of-bar-files strategies.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Jim Newton wrote:
> An objection some people seem to have about CLOS is the
> problem of code organization.
Aside: If that is there bottom-line assessment of CLOS, then really they
are just looking for a way (any way) to denigrate something with which
they are unfamiliar.
Which file do you put
> a method definition in?
Most often with the class on which arg0 is specialized. Sometimes I use
GFs instead of a typecase on null, a number, a string, and whatever.
Then I group them together. But doing that is hard if I am specializing
on something other than built-ins, because the specialized method
definition cannot precede the class definition.
In languages like C++ and Python
> you are forced to put the methods INSIDE the class definition.
> Thus you do not have any freedom in code organization.
...or anything else. Which is the problem. CLOS offers :around, :before,
and :after methods. The people reading your code cannot possibly find
the code behind a method invocation without knowing the class precedence
list and the full list of method definitions. ie, What if some :around
method on a higher class is not even invoking call-next-method under
certain circumstances. Which brings me to the big point:
I wager they really are just reading the code, without the benefit of a
decent IDE. The ones I have used all pop up a modeless dialog (or pop-up
menu) listing all the methods on a GF at the stroke of a keychord. I
still have to pick out the one I want, but that has not killed me yet.
> In CLOS, methods do not belong to classes except conceptually
> at a very high level, and then only excluding multi-methods.
In my experience, multi-methods are still specialized on arg0, and so
can still be grouped with that class. I almost never leave the first
argument unspecialized and then specialize a later arg. When I do, it is
usually an :around or :before/after method just splicing in a little
necessary code to support those classes.
>
>
> Should you group defmethods by class, or by generic function?
> Or should you simply group defmethods together which are
> semantically related?
>
> In my own opinion, it seems ok to use some mixture of
> these coding styles, whatever makes sense at the time.
> But people who read my code sometimes complain that
> they never know where to find the appropriate defmethod.
They're gonna love Smalltalk. :)
>
> Are there guidelines for code orginization which seem
> to make code more readable? Is "readable" for the expert
> different from "readable" to the beginner?
>
A recent thread suggests it varies among experts as well, but the
precise context is instructive: we were debating IDEs, not code
organization.
kt
--
Home? http://tilton-technology.com
Cells/Cello/Celtik? http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Jim Newton wrote:
> An objection some people seem to have about CLOS is the
> problem of code organization. Which file do you put
> a method definition in? In languages like C++ and Python
> you are forced to put the methods INSIDE the class definition.
> Thus you do not have any freedom in code organization.
> In CLOS, methods do not belong to classes except conceptually
> at a very high level, and then only excluding multi-methods.
>
> Should you group defmethods by class, or by generic function?
> Or should you simply group defmethods together which are
> semantically related?
Since in other languages, you are forced to place methods inside
classes, the users of those languages have to invent things like the
Visitor pattern in order to be able to group methods according to their
functionality. The fact that something like the Visitor pattern exists
is a proof that they actually also want the same degree of freedom that
we take for granted.
> In my own opinion, it seems ok to use some mixture of
> these coding styles, whatever makes sense at the time.
> But people who read my code sometimes complain that
> they never know where to find the appropriate defmethod.
Good IDEs support you in finding the respective methods, base on either
the generic function or on the classes for which they are defined.
> Are there guidelines for code orginization which seem
> to make code more readable? Is "readable" for the expert
> different from "readable" to the beginner?
Probably yes. It's like playing chess: As a beginner you have to
actively remember all the moves that the various figures can make and
think very locally, while as an expert you start to constellations and
whole sequences of recurring strategies.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)