From: Peter Seibel
Subject: CLOS style question
Date: 
Message-ID: <m3llpmmrxo.fsf@javamonkey.com>
I imagine different folks have different style preferences but I'm
curious what the main variants are: how do you name the parameters to
generic functions and methods.

I find myself usually having an idea what the base types (i.e. least
specialized) I will be specializing things on and since that's all I
know at the point I write the gf, I tend to use the class name as the
name of the parameter. E.g.

  (defgeneric send-message (message protocol)
    (:documentation "Send a message using a particular protocol object."))

Then when I go to write methods for this gf there are a couple ways to
go--I tend to leave the parameter name the same like this:

  (defmethod send-message ((message hello-message) (protocol xml-protocol)) ...)

But sometimes that leaves me with pretty generic parameter names. And
then sometimes when I'm writing methods that use single-dispatch (i.e.
all other parameters are specialized on T) sometimes I'm tempted to
call the dispatching parameter 'self' or 'this'. That's probably just
left-over Java lossage though.

Anyway, does anyone have a consistent naming convention that they can
articulate and want to share?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

From: Frank A. Adrian
Subject: Re: CLOS style question
Date: 
Message-ID: <pan.2003.12.09.16.12.57.4482@ancar.org>
On Tue, 09 Dec 2003 06:26:41 +0000, Peter Seibel wrote:

> Then when I go to write methods for this gf there are a couple ways to
> go--I tend to leave the parameter name the same like this:
> 
>   (defmethod send-message ((message hello-message) (protocol xml-protocol)) ...)

I am usually even more cryptic:
   (defmethod send-message ((m hello-message)) (p xml-protocol)) ...)

This is for two reasons:
(1) My methods tend to be short (a holdover from my Smalltalk days), so
the parameter, its type, and the code that uses it are all usually visible
within a single edit pane;
(2) I don't like typing long names (a holdover from C and C++).


> But sometimes that leaves me with pretty generic parameter names. And
> then sometimes when I'm writing methods that use single-dispatch (i.e.
> all other parameters are specialized on T) sometimes I'm tempted to call
> the dispatching parameter 'self' or 'this'. That's probably just
> left-over Java lossage though.

I never do that!  'self' and 'this' are too long to type!


> Anyway, does anyone have a consistent naming convention that they can
> articulate and want to share?

Probably as many as there are readers on this board...

faa
From: Arthur Lemmens
Subject: Re: CLOS style question
Date: 
Message-ID: <oprzwm5kyqk6vmsw@news.xs4all.nl>
Peter Seibel <·····@javamonkey.com> wrote:

> I imagine different folks have different style preferences but I'm
> curious what the main variants are: how do you name the parameters to
> generic functions and methods.

I use pretty much the same style that you describe.

> Then when I go to write methods for this gf there are a couple ways to
> go--I tend to leave the parameter name the same like this:
>
> (defmethod send-message ((message hello-message) (protocol xml-protocol)) ...)
>
> But sometimes that leaves me with pretty generic parameter names.

Do you see a problem with that? I don't. On the contrary, having a
'pretty generic parameter name' gives you a bit more flexibility with
the class names. E.g., when you later decide that HELLO-MESSAGE is not
really the right name and you'd better call it WELCOME-MESSAGE (this
happens to me all the time, especially in the early stages of a design),
at least you don't have to replace all the parameter names.

> And then sometimes when I'm writing methods that use single-dispatch (i.e.
> all other parameters are specialized on T) sometimes I'm tempted to
> call the dispatching parameter 'self' or 'this'. That's probably just
> left-over Java lossage though.

I don't think so. I've seen SELF parameters in CLOS code that was written
before Java even existed. It has the same advantage that you can easily
rename a class without bothering to change the body of a method.

Arthur Lemmens
From: Kent M Pitman
Subject: Re: CLOS style question
Date: 
Message-ID: <sfwd6ayezvg.fsf@shell01.TheWorld.com>
Arthur Lemmens <········@xs4all.nl> writes:

> Peter Seibel <·····@javamonkey.com> wrote:
> > I'm tempted to call the dispatching parameter 'self' or 'this'. 
> > That's probably just left-over Java lossage though.

> I don't think so. I've seen SELF parameters in CLOS code that was written
> before Java even existed. It has the same advantage that you can easily
> rename a class without bothering to change the body of a method.

I used to use SELF parameters as a crutch coming in from Flavors and other
earlier object-oriented systems.  Such systems are surely where it came from.

But these days I almost never find myself doing that, though.  It's
rarely adequately descriptive.  It makes for lousy arglist documentation,
for example, if someone types control-shift-A in an Emacs-like editor to
see what args the thing takes.  If you just have the operation-name, how
are you supposed to know what a 'self' is.  At worst, just use the type
of the object.  (FROB FROB) is much better than (SELF FROB).

I think the key, if you really want to get into the CLOS mindset, is
to not think of generic functions as "part" of the object.  They are
operations that may incidentally involve an object, but they are not
owned by the object.

Imagine how it would feel if you were working for a bank and in order to
get into the safe it asked for a bunch of data from three people standing
there and the dialog went like:

  Please enter your name:  Joe
  Bzzzt. Try again
  Please enter your name:  Bill
  Bzzzt. Try again
  Please enter your name:  Sally
  Bzzzt. Try again
  Please enter your name:  there's no one else here
  Bzzzt. Invalid syntax.
  Please enter your name:  hint
  Remember that this program was written Peter Seibel.
  Put yourself in his shoes and try to figure out what class he
  thought the OPEN-SESAME generic operation belonged to.
  Please enter your name:  Acme Safe Model 3A, Serial Number 1733432
  Congratulations.  You may continue to the next question.

Pronouns like your/my are related to point of view.  Same with SELF.
In CLOS, you enter a point of view when you go into WITH-SLOTS, and
even then you can be in several points of view if you layer multiple
instances slots as in

 (DEFMETHOD FOO ((FROB1 FROB) (FROB2 FROB))
   (WITH-SLOTS (X1 Y1 Z1) FROB1
     (WITH-SLOTS (X2 Y2 Z2) FROB2
       ...)))

Think of it as an exercise like an English teacher would do to you
asking you to write the same story as you'd just written in first-person
(using self) instead in third-person (using him/her/it ... or some other
more descriptive common noun).
From: Fred Gilham
Subject: Re: CLOS style question
Date: 
Message-ID: <u77k16udvj.fsf@snapdragon.csl.sri.com>
Kent Pitman wrote:
> I think the key, if you really want to get into the CLOS mindset, is
> to not think of generic functions as "part" of the object.  They are
> operations that may incidentally involve an object, but they are not
> owned by the object.

I think this is exactly what always made me feel funny about code
which uses "self" for the names of arguments to methods, though I have
seen it a lot.

There's this guy who did a critique of object oriented programming:

  http://www.geocities.com/SiliconValley/Lab/6888/oopbad.htm

He advocates "table-driven" programming.  I think his approach is
actually in the spirit of generic functions.

-- 
Fred Gilham                                        ······@csl.sri.com
Perhaps the greatest damage the American system of education has done
to its children is to teach them that their opinions are relevant
simply because they are their opinions.
From: Will Hartung
Subject: Re: CLOS style question
Date: 
Message-ID: <br6116$28ilq5$1@ID-197644.news.uni-berlin.de>
"Fred Gilham" <······@snapdragon.csl.sri.com> wrote in message
···················@snapdragon.csl.sri.com...

> There's this guy who did a critique of object oriented programming:
>
>   http://www.geocities.com/SiliconValley/Lab/6888/oopbad.htm
>
> He advocates "table-driven" programming.  I think his approach is
> actually in the spirit of generic functions.

I dunno about that, this guy seems a bit out on the fringe to me.

But, anyway, there is a development tool from a place called Magic Software
that advocates their own version of "table programming". Been around for
years, but when I looked at is years ago, it wasn't instantly grokkable to
me.

Regards,

Will Hartung
(·····@msoft.com)
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: CLOS style question
Date: 
Message-ID: <pan.2003.12.09.18.15.34.342415@knm.org.pl>
On Tue, 09 Dec 2003 08:58:40 -0800, Fred Gilham wrote:

> There's this guy who did a critique of object oriented programming:
> 
>   http://www.geocities.com/SiliconValley/Lab/6888/oopbad.htm
> 
> He advocates "table-driven" programming.  I think his approach is
> actually in the spirit of generic functions.

I don't think so. Look at
<http://www.geocities.com/SiliconValley/Lab/6888/guitable.htm>,
especially Param1, Value1, Param2, Value2. He is insane.

He doesn't advocate generic functions. He advocates using the same
representation for each possible subtype of the given abstract type, and
writing monolithic non-generic functions which handle all combinations
of parameters, probably by giant case statements.

Sometimes he uses things like "function name or snippet when clicked".
Seems he doesn't like closures either. I guess it's because they resemble
objects too much :-)

He exclusively uses product types and primitive types - no sum types,
prefers imperative to functional, global variables to local, and keys
from another table to pointers (this rules out garbage collection).

While I hate traditional OO coupling of functions with data and writing
all functions operating on the given type in one place, I'm definitely in
favor of dynamic dispatch, either statically typed (algebraic types with
pattern matching) or dynamically (generic functions).

-- 
   __("<         Marcin Kowalczyk
   \__/       ······@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/
From: Michael Naunton
Subject: Re: CLOS style question
Date: 
Message-ID: <slrnbto1da.gt3.mmn@micron.bellatlantic.net>
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> 
> Kent Pitman wrote:
>> I think the key, if you really want to get into the CLOS mindset, is
>> to not think of generic functions as "part" of the object.  They are
>> operations that may incidentally involve an object, but they are not
>> owned by the object.
> 
> I think this is exactly what always made me feel funny about code
> which uses "self" for the names of arguments to methods, though I have
> seen it a lot.
> 
> There's this guy who did a critique of object oriented programming:
> 
>   http://www.geocities.com/SiliconValley/Lab/6888/oopbad.htm
> 
> He advocates "table-driven" programming.  I think his approach is
> actually in the spirit of generic functions.
> 

Ah, more Topmind pages (google for "Topmind" in groups: he's a well-known 
internet loon.) Sadly, his critiques of C++ type OOP are quite good, but 
he proposes a horrible system to replace them.  If he could just spend 
a year or two at a serious Lisp shop, he might actually become a good 
architect.

-- MMN
From: Topmind
Subject: Re: CLOS style question
Date: 
Message-ID: <4e705869.0312281226.3338477e@posting.google.com>
> > 
> > Kent Pitman wrote:
> >> I think the key, if you really want to get into the CLOS mindset, is
> >> to not think of generic functions as "part" of the object.  They are
> >> operations that may incidentally involve an object, but they are not
> >> owned by the object.
> > 
> > I think this is exactly what always made me feel funny about code
> > which uses "self" for the names of arguments to methods, though I have
> > seen it a lot.
> > 
> > There's this guy who did a critique of object oriented programming:
> > 
> >   http://www.geocities.com/SiliconValley/Lab/6888/oopbad.htm
> > 
> > He advocates "table-driven" programming.  I think his approach is
> > actually in the spirit of generic functions.
> > 
> 
> Ah, more Topmind pages (google for "Topmind" in groups: he's a well-known 
> internet loon.) Sadly, his critiques of C++ type OOP are quite good, but 
> he proposes a horrible system to replace them.  If he could just spend 
> a year or two at a serious Lisp shop, he might actually become a good 
> architect.

If CLOS is so good, then why not show the world how 
good it is? What does it do better in 
the real world? Tables can show
row-wise patterns and column-wise patterns at the
same time. Lists cannot readily do this unless you
have special eyes (although the info can 
be stored as lists if need be.) Calling people names 
and then appealing to your own authority does nobody 
any good. As I like to say, show it or shove it.

Better yet, convince Paul Graham of CLOS first.

-Topmind-

> 
> -- MMN
From: Pascal Costanza
Subject: Re: CLOS style question
Date: 
Message-ID: <3FEF4288.7050100@web.de>
Topmind wrote:

> If CLOS is so good, then why not show the world how 
> good it is? 

That's an especially bad criterion. If "the world" would be the most 
important indicator of quality, then we would all be programming Visual 
Basic.

> What does it do better in 
> the real world?

http://alu.cliki.net/Evaluate%20Lisp lists several arguments.

> Tables can show
> row-wise patterns and column-wise patterns at the
> same time. 

Yes, and this is good. However, an important concept in software 
engineering is incremental development. If you have a good sense of how 
your software might evolve in the future, and you can mold this either 
in functional or object-oriented abstractions, then you can get a lot of 
benefit of the reduced need to consider many dimensions when extending 
the code later on.

The table-oriented approach, as far as I understand it, makes you always 
think in the two dimensions functions and data, even if it wouldn't be 
necessary.

I don't believe in the superiority of one single paradigm over all 
others. I think there are lots of very different domains, and each 
strictly deserves their own paradigm. However, there are recurring 
patterns, and it makes sense to make these patterns available in the 
form of higher-level constructs. And this is what Common Lisp is 
especially good at. For example, the Common Lisp Object System is 
essentially just a bunch of high-level macros.

It would be cool to have a table-oriented approach available as a set of 
macros integrated with the rest of Common Lisp. I am pretty sure that 
this is feasible and welcome here.

> Lists cannot readily do this unless you
> have special eyes (although the info can 
> be stored as lists if need be.)

...but since lists are not the most important data structure in Common 
Lisp, this is not an especially interesting argument. I hope you don't 
draw your opinions from old-fashioned Lisp dialects that didn't have 
much else beyond lists.

> Calling people names 
> and then appealing to your own authority does nobody 
> any good. As I like to say, show it or shove it.
> 
> Better yet, convince Paul Graham of CLOS first.

Lisp attracts people who are fond of developing a personal programming 
style. This has both advantages and disadvantages.

Especially, this means that there is no one single right way to do 
things with Lisp, as is fashionable for many other languages nowadays.

Paul Graham has equally good reasons to abandon CLOS as have others to 
actually use it. It is important to understand the trade-offs. (And I 
think your site mentions several excellent reasons why OOP is not a 
silver bullet, which are worthwhile to study.)


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Christopher C. Stacy
Subject: Re: CLOS style question
Date: 
Message-ID: <uy8swjy4b.fsf@news.dtpq.com>
>>>>> On 28 Dec 2003 12:26:13 -0800, Topmind  ("Topmind") writes:
 Topmind> Tables can show row-wise patterns and column-wise patterns
 Topmind> at the same time. Lists cannot readily do this unless you
 Topmind> have special eyes

>>>>> On Sun, 28 Dec 2003 21:52:24 +0100, Pascal Costanza ("Pascal") writes:
 Pascal> I hope you don't draw your opinions from old-fashioned Lisp dialects

I think all he was asserting that tablular data structures are hard to
read ("unless you have special eyes") if they are delimited by parenthesis.  
I see tabular data, especially control data (such as dispatch tables)
written using list syntax all the time.  Whether someone would find
that hard to read is a purely a matter of personal opinion.

If anyone is under the impression that Lisp only has lists as its
constructive data type, then "old-fashioned" is an understatement.
Let me correct any assumption that arrays were something added in 
the 1980s: Lisp has had tabluar data structures such as arrays for 
at least the past 32 (could be 38) years.

I think the real issue that Topmind is trying to think about is not
how whether tabular data is implemented using lists, but rather how it
is presented.  In Lisp (or any language, I suppose) one can implement
any desired kind of tablular-oriented user interface.  People commonly
have tabular, directed graph, and other kinds of presentations that
they use for displaying program control elements in Lisp-based systems.  
In the Lisp world, alternative ways of describing programs and this
kind of technology dates from the 1970s.  A lot of research was done
in this area around 1982, when graphical display technology 
(ie. Lisp Machines) was more commonly available in the labs.
Suggesting that tables are the best control structure for a
general-purpose programming language seems awfully simplistic.
From: Pascal Costanza
Subject: Re: CLOS style question
Date: 
Message-ID: <bsntq8$k56$1@newsreader2.netcologne.de>
Christopher C. Stacy wrote:

>>>>>>On 28 Dec 2003 12:26:13 -0800, Topmind  ("Topmind") writes:
> 
>  Topmind> Tables can show row-wise patterns and column-wise patterns
>  Topmind> at the same time. Lists cannot readily do this unless you
>  Topmind> have special eyes
> 
> 
>>>>>>On Sun, 28 Dec 2003 21:52:24 +0100, Pascal Costanza ("Pascal") writes:
> 
>  Pascal> I hope you don't draw your opinions from old-fashioned Lisp dialects
> 
> I think all he was asserting that tablular data structures are hard to
> read ("unless you have special eyes") if they are delimited by parenthesis.  
> I see tabular data, especially control data (such as dispatch tables)
> written using list syntax all the time.  Whether someone would find
> that hard to read is a purely a matter of personal opinion.
> 
> If anyone is under the impression that Lisp only has lists as its
> constructive data type, then "old-fashioned" is an understatement.
> Let me correct any assumption that arrays were something added in 
> the 1980s: Lisp has had tabluar data structures such as arrays for 
> at least the past 32 (could be 38) years.
> 
> I think the real issue that Topmind is trying to think about is not
> how whether tabular data is implemented using lists, but rather how it
> is presented.  In Lisp (or any language, I suppose) one can implement
> any desired kind of tablular-oriented user interface.  People commonly
> have tabular, directed graph, and other kinds of presentations that
> they use for displaying program control elements in Lisp-based systems.  
> In the Lisp world, alternative ways of describing programs and this
> kind of technology dates from the 1970s.  A lot of research was done
> in this area around 1982, when graphical display technology 
> (ie. Lisp Machines) was more commonly available in the labs.
> Suggesting that tables are the best control structure for a
> general-purpose programming language seems awfully simplistic.

Thanks a lot for your clarifications!


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Topmind
Subject: Re: CLOS style question
Date: 
Message-ID: <4e705869.0312292110.156e32f8@posting.google.com>
> 
> I think all he was asserting that tablular data structures are hard to
> read ("unless you have special eyes") if they are delimited by parenthesis.  
> I see tabular data, especially control data (such as dispatch tables)
> written using list syntax all the time.  Whether someone would find
> that hard to read is a purely a matter of personal opinion.

A lot of things are. Tables work for me when information can
fit into tables. Suffice to say that different things are
easier to grok and study in different formats and representations.
The options generally are:
  * Program code
  * Tables (grids)
  * Diagrams
  * Wysiwyg (GUI designers, etc.)  

Either I just find that more things work better as tables
than other people, or else others have yet to see them
fully in action and don't know their strength.

Too many things that others seem to like as code and/or
hierarchical files, I would much rather see as tables
and be able to query them in a relational language to
filter and alter my view of them as I please. Tables 
are easier to transform via expressions than code.
I am not stuck with Bill Gate's view nor Paul Graham's,
but the one that I want and need for the moment.

> 
> If anyone is under the impression that Lisp only has lists as its
> constructive data type, then "old-fashioned" is an understatement.
> Let me correct any assumption that arrays were something added in 
> the 1980s: Lisp has had tabluar data structures such as arrays for 
> at least the past 32 (could be 38) years.
> 
> I think the real issue that Topmind is trying to think about is not
> how whether tabular data is implemented using lists, but rather how it
> is presented.  In Lisp (or any language, I suppose) one can implement
> any desired kind of tablular-oriented user interface.  People commonly
> have tabular, directed graph, and other kinds of presentations that
> they use for displaying program control elements in Lisp-based systems.  
> In the Lisp world, alternative ways of describing programs and this
> kind of technology dates from the 1970s.  A lot of research was done
> in this area around 1982, when graphical display technology 
> (ie. Lisp Machines) was more commonly available in the labs.
> Suggesting that tables are the best control structure for a
> general-purpose programming language seems awfully simplistic.

See above.
   
-T-
From: Christopher C. Stacy
Subject: Re: CLOS style question
Date: 
Message-ID: <ullou500j.fsf@news.dtpq.com>
>>>>> On 29 Dec 2003 21:10:12 -0800, Topmind  ("Topmind") writes:
 Topmind> Either I just find that more things work better as tables
 Topmind> than other people, or else others have yet to see them
 Topmind> fully in action and don't know their strength.

 Topmind> Too many things that others seem to like as code and/or
 Topmind> hierarchical files, I would much rather see as tables
 Topmind> and be able to query them in a relational language to
 Topmind> filter and alter my view of them as I please. Tables 
 Topmind> are easier to transform via expressions than code.
 Topmind> I am not stuck with Bill Gate's view nor Paul Graham's,
 Topmind> but the one that I want and need for the moment.

That's nice for you.

What's this got to do with Lisp again?
From: Rahul Jain
Subject: Re: CLOS style question
Date: 
Message-ID: <87d6a692bl.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> What's this got to do with Lisp again?

He's saying that the Lisp Way agrees perfectly with his ideals, of
course.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Pascal Costanza
Subject: Re: CLOS style question
Date: 
Message-ID: <bsrvpj$4fh$1@newsreader2.netcologne.de>
Christopher C. Stacy wrote:
>>>>>>On 29 Dec 2003 21:10:12 -0800, Topmind  ("Topmind") writes:
> 
>  Topmind> Either I just find that more things work better as tables
>  Topmind> than other people, or else others have yet to see them
>  Topmind> fully in action and don't know their strength.
> 
>  Topmind> Too many things that others seem to like as code and/or
>  Topmind> hierarchical files, I would much rather see as tables
>  Topmind> and be able to query them in a relational language to
>  Topmind> filter and alter my view of them as I please. Tables 
>  Topmind> are easier to transform via expressions than code.
>  Topmind> I am not stuck with Bill Gate's view nor Paul Graham's,
>  Topmind> but the one that I want and need for the moment.
> 
> That's nice for you.
> 
> What's this got to do with Lisp again?

For example, it would be a cool idea to integrate his approach into 
Common Lisp as an additional paradigm, similar to CLOS or maybe Kenny's 
Cells. I think his approach is interesting enough in that regard.

While I don't have the time to do that, this would be a good project for 
a Lisp newbie to learn how to work macros and/or the MOP IMHO. Maybe it 
turns out more problematic than I expect right now, but at least you 
would learn a good deal about Lisp during the course. Just a suggestion...


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Arthur Lemmens
Subject: Re: CLOS style question
Date: 
Message-ID: <oprzxs4bbkk6vmsw@news.xs4all.nl>
Kent M Pitman writes:

> I used to use SELF parameters as a crutch coming in from Flavors and other
> earlier object-oriented systems.  Such systems are surely where it came from.
>
> But these days I almost never find myself doing that, though.  It's
> rarely adequately descriptive.  It makes for lousy arglist documentation,
> for example, if someone types control-shift-A in an Emacs-like editor to
> see what args the thing takes.

Yes. I sometimes use SELF as a parameter name in methods that only specialize
on one parameter, mostly because it's short and I can't think of a better name
that wouldn't be much longer; it's a bit like calling a loop index 'I' instead
of, say, 'POSITION' in situations where the context makes it abundantly clear
what your variable is doing anyway.

But I'd never use SELF it as the parameter name for a generic function
(if only, like you say, because I use control-shift-A all the time).

Arthur Lemmens
From: steve
Subject: Re: CLOS style question
Date: 
Message-ID: <111220030105039932%sal6741@hotmail.com>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@nhplace.com> wrote:

> Arthur Lemmens <········@xs4all.nl> writes:
> 
> > Peter Seibel <·····@javamonkey.com> wrote:
> > > I'm tempted to call the dispatching parameter 'self' or 'this'. 
> > > That's probably just left-over Java lossage though.
> 
> > I don't think so. I've seen SELF parameters in CLOS code that was written
> > before Java even existed. It has the same advantage that you can easily
> > rename a class without bothering to change the body of a method.
> 
> I used to use SELF parameters as a crutch coming in from Flavors and other
> earlier object-oriented systems.  Such systems are surely where it came from.
> 
> But these days I almost never find myself doing that, though.  It's
> rarely adequately descriptive.  It makes for lousy arglist documentation,
> for example, if someone types control-shift-A in an Emacs-like editor to
> see what args the thing takes.  If you just have the operation-name, how
> are you supposed to know what a 'self' is.  At worst, just use the type
> of the object.  (FROB FROB) is much better than (SELF FROB).
> 
> I think the key, if you really want to get into the CLOS mindset, is
> to not think of generic functions as "part" of the object.  They are
> operations that may incidentally involve an object, but they are not
> owned by the object.
> 
> Imagine how it would feel if you were working for a bank and in order to
> get into the safe it asked for a bunch of data from three people standing
> there and the dialog went like:
> 
>   Please enter your name:  Joe
>   Bzzzt. Try again
>   Please enter your name:  Bill
>   Bzzzt. Try again
>   Please enter your name:  Sally
>   Bzzzt. Try again
>   Please enter your name:  there's no one else here
>   Bzzzt. Invalid syntax.
>   Please enter your name:  hint
>   Remember that this program was written Peter Seibel.
>   Put yourself in his shoes and try to figure out what class he
>   thought the OPEN-SESAME generic operation belonged to.
>   Please enter your name:  Acme Safe Model 3A, Serial Number 1733432
>   Congratulations.  You may continue to the next question.
> 
> Pronouns like your/my are related to point of view.  Same with SELF.
> In CLOS, you enter a point of view when you go into WITH-SLOTS, and
> even then you can be in several points of view if you layer multiple
> instances slots as in
> 
>  (DEFMETHOD FOO ((FROB1 FROB) (FROB2 FROB))
>    (WITH-SLOTS (X1 Y1 Z1) FROB1
>      (WITH-SLOTS (X2 Y2 Z2) FROB2
>        ...)))
> 
> Think of it as an exercise like an English teacher would do to you
> asking you to write the same story as you'd just written in first-person
> (using self) instead in third-person (using him/her/it ... or some other
> more descriptive common noun).
> 
> 

I use a SELF variable for methods which implement the lazy-evaluation
behavior I sometimes want in classes. In this case, SELF is just the
class instance that allows a macro called THIS to access other slot
values within the instance and its child components (using a simple
form of reference chaining.) I can't remember why I call the variable
SELF, but I suspect it is because I couldn't think of an alternative.

sl
From: Thomas F. Burdick
Subject: Re: CLOS style question
Date: 
Message-ID: <xcvvfopcx7y.fsf@famine.OCF.Berkeley.EDU>
Peter Seibel <·····@javamonkey.com> writes:

> I imagine different folks have different style preferences but I'm
> curious what the main variants are: how do you name the parameters to
> generic functions and methods.
> 
> I find myself usually having an idea what the base types (i.e. least
> specialized) I will be specializing things on and since that's all I
> know at the point I write the gf, I tend to use the class name as the
> name of the parameter. E.g.
> 
>   (defgeneric send-message (message protocol)
>     (:documentation "Send a message using a particular protocol object."))
> 
> Then when I go to write methods for this gf there are a couple ways to
> go--I tend to leave the parameter name the same like this:
> 
>   (defmethod send-message ((message hello-message) (protocol xml-protocol)) ...)
> 
> But sometimes that leaves me with pretty generic parameter names.

I don't think that's a problem, especially for the generic function.
When writing methods, you can give the parameters more specifically
descriptive names where the documentation would be useful, and/or
short easy to type names for convenience.  For example, I might write
a method on that gf that goes like:

  (defmethod send-message (m (protospec symbol))
    (send-message m (find-protocol protospec)))

> And
> then sometimes when I'm writing methods that use single-dispatch (i.e.
> all other parameters are specialized on T) sometimes I'm tempted to
> call the dispatching parameter 'self' or 'this'. That's probably just
> left-over Java lossage though.
> 
> Anyway, does anyone have a consistent naming convention that they can
> articulate and want to share?

I'm much more likely to name such a parameter "obj", or its class's
name, or a short variation of its class's name.  Sometimes it's useful
to have GFs that you mentally model as "send message F to object O",
like in Smalltalk.  In that case, I call the reciever either self or
reciever.  That's about the only time I call a parameter "self".  I
got out of the habit when I wanted to get used to writing more
GF-centric code.

For your audience, I'd recommend you avoid calling anything "self" in
your book.  It can be stylistically okay, but I bet it will hinder a
good number of people's ability to "get" GFs.  Some will use it
correctly, but some will just grab onto it as a Java crutch.

This reminds me of LOOP.  I avoided using it for a long time, because
I wanted to get a feel for the Lispy way of doing iteration, and felt
that LOOP would make it too easy to just think in Algol-ish terms.
Eventually, once I got comfortable with Lisp, I gave LOOP a chance,
and I love it now!  Every once it a while, it's great to ease into a
comfortable pair of Algolish iteration constructs -- and the same
thing goes for C++-like OOP.  But bluejeans aren't always appropriate,
and if you aren't comfotable dressing well, you might find that you're
the guy in a polo shirt at a 4-star restaurant.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Kenny Tilton
Subject: Re: CLOS style question
Date: 
Message-ID: <denBb.381809$pT1.61954@twister.nyc.rr.com>
Peter Seibel wrote:
> I imagine different folks have different style preferences but I'm
> curious what the main variants are: how do you name the parameters to
> generic functions and methods.
> 
> I find myself usually having an idea what the base types (i.e. least
> specialized) I will be specializing things on and since that's all I
> know at the point I write the gf, I tend to use the class name as the
> name of the parameter. E.g.
> 
>   (defgeneric send-message (message protocol)
>     (:documentation "Send a message using a particular protocol object."))

That looks fine, but what do you do if some other function takes two 
messages as parameters? Or one parameter is known up front to be one of 
a fixnum, point, or rectangle (and the generic is being written 
precisely to cleanly handle each case in a separate method)? The 
reductio ad absurdum is, what about then the argument is a fixnum?

> 
> Then when I go to write methods for this gf there are a couple ways to
> go--I tend to leave the parameter name the same like this:
> 
>   (defmethod send-message ((message hello-message) (protocol xml-protocol)) ...)

I'm with Frank on the names m and p. It is a convention I use to signify 
that "this bad boy is a parameter" and, yes, saves a lot of typing.

As for using the function signature as documentation, you know, I hear 
that a lot and it confuses me because I never use it that way. If I am 
that clueless as to the nature of a function I just hit 
control-alt-period in ACL and I am looking at the function, or I hit F1 
and I am looking at the online doc or the HyperSpec.

Maybe when/if I spend more time on different IDEs I'll start sweating 
signatures qua doc.

> 
> But sometimes that leaves me with pretty generic parameter names. And
> then sometimes when I'm writing methods that use single-dispatch (i.e.
> all other parameters are specialized on T) sometimes I'm tempted to
> call the dispatching parameter 'self' or 'this'. That's probably just
> left-over Java lossage though.

It is an extremely rare GF that does not have one parameter that  can be 
viewed as self, and in my intensive use of clos I have been surprised to 
discover that self works much better than a name that gives away the 
type. Many a time when I used something other than self, when cloning or 
refactoring I found myself tediously tracking down the parameter name to 
change the embedded type reference.

It is a natural tendency, esp. when coming from statically-typed 
languages, to be so obsessed with type that we put it in the variable 
name. But that is a big mistake; the arguments to make-point should not 
be x-int and y-int.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Kent M Pitman
Subject: Re: CLOS style question
Date: 
Message-ID: <sfwvfopkeez.fsf@shell01.TheWorld.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> It is an extremely rare GF that does not have one parameter that  can
> be viewed as self, 

This isn't the issue.  The issue is whether that's a paradigm, the use of
which, adds power to the frame of mind.  Thinking in terms of self is bad
for the same reason as thinking the sun revolves around the earth.  If you
make a mistake about what is central, it will lead you down the garden path
toward making your operations way more complicated than you should.  By 
inhibiting, to the extent you can, any notion of central focus, you remain
open-minded to the possibility of reversing the centrality as a matter of
personal programming style.  Since arglists are frequently published, they
are not a good place to manifest this personal style.
From: Kenny Tilton
Subject: Re: CLOS style question
Date: 
Message-ID: <YtpBb.382898$pT1.117085@twister.nyc.rr.com>
Kent M Pitman wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>It is an extremely rare GF that does not have one parameter that  can
>>be viewed as self, 
> 
> 
> This isn't the issue.  The issue is whether that's a paradigm, the use of
> which, adds power to the frame of mind.  Thinking in terms of self is bad
> for the same reason as thinking the sun revolves around the earth.  If you
> make a mistake about what is central, 

My comment was meant to indicate that, in my experience, almost every GF 
has a parameter which is indeed the central focus of the method 
semantics. When I see "self" in the code of a GF, I am done. I know 
exactly what it is, as long as I know what function I am looking at (joke).

I invite nay-sayers to dig into existing actual code (spare me the 
foo-bars) and provide examples of GFs with no such primary target. I 
would expect comparison or combination functions, such as > or + (only 
then I would not expect generics).

it will lead you down the garden path
> toward making your operations way more complicated than you should.  By 
> inhibiting, to the extent you can, any notion of central focus, you remain
> open-minded to the possibility of reversing the centrality as a matter of
> personal programming style. 

Personal style has nothing to do with it. A GF's semantics either do or 
do not focus on one particular parameter, no matter how 
liberal/illiberal we want to be about what revolves around what. Put 
another way, if a GF does focus on one parameter (and they all do), 
pretending it does not in the name of open-mindedness simply hides 
information.

btw, an important unspoken is that I still prefix methods with something 
that gives away the "self" being worked on. "ix-this" and "wdw-that". So 
seeing self in the signature is never ambiguous.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Ingvar Mattsson
Subject: Re: CLOS style question
Date: 
Message-ID: <87u149k7gg.fsf@gruk.tech.ensign.ftech.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> Kent M Pitman wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>It is an extremely rare GF that does not have one parameter that  can
> >> be viewed as self,
> > This isn't the issue.  The issue is whether that's a paradigm, the
> > use of
> > which, adds power to the frame of mind.  Thinking in terms of self is bad
> > for the same reason as thinking the sun revolves around the earth.  If you
> > make a mistake about what is central,
> 
> My comment was meant to indicate that, in my experience, almost every
> GF has a parameter which is indeed the central focus of the method
> semantics. When I see "self" in the code of a GF, I am done. I know
> exactly what it is, as long as I know what function I am looking at
> (joke).
> 
> I invite nay-sayers to dig into existing actual code (spare me the
> foo-bars) and provide examples of GFs with no such primary target. I
> would expect comparison or combination functions, such as > or + (only
> then I would not expect generics).

Adding a route to a table? What is more central, the route being added
or the table it gets added to? There is at least two distinct types of
(IP) routing tables, namely a FIB (rorwarding information base, this
is what decides what packet goes where, now) and one or more RIBs
(routing information base, this is where the static and dynamic
routing lives that then determine what ends up in the FIB). Routes with
identical prefix but different background may be duplicated in a RIB
but may not be in a FIB.

Depending on the angle I look at this, I am equally well prepared to
argue for "the route is the central thing" and "the table is the
central thing".

I *do* have code, if you necessarily want to see it, but it needs
fixing, since it currently does not distinguish properly between FIBs
and RIBs.

//Ingvar
-- 
"No. Most Scandiwegians use the same algorithm as you Brits.
 "Ingvar is just a freak."
Stig Morten Valstad, in the Monastery
From: Kenny Tilton
Subject: Re: CLOS style question
Date: 
Message-ID: <tBrBb.383540$pT1.244998@twister.nyc.rr.com>
Ingvar Mattsson wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>Kent M Pitman wrote:
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>It is an extremely rare GF that does not have one parameter that  can
>>>>be viewed as self,
>>>
>>>This isn't the issue.  The issue is whether that's a paradigm, the
>>>use of
>>>which, adds power to the frame of mind.  Thinking in terms of self is bad
>>>for the same reason as thinking the sun revolves around the earth.  If you
>>>make a mistake about what is central,
>>
>>My comment was meant to indicate that, in my experience, almost every
>>GF has a parameter which is indeed the central focus of the method
>>semantics. When I see "self" in the code of a GF, I am done. I know
>>exactly what it is, as long as I know what function I am looking at
>>(joke).
>>
>>I invite nay-sayers to dig into existing actual code (spare me the
>>foo-bars) and provide examples of GFs with no such primary target. I
>>would expect comparison or combination functions, such as > or + (only
>>then I would not expect generics).
> 
> 
> Adding a route to a table? What is more central, the route being added
> or the table it gets added to? 

Subject: table
Verb: add
Object: route

What was the name of the function? I would have:

  table-add
  table-remove
  table-replace
  table-list

Why is table central? You are changing the table, not the route. If the 
table were somehow an attribute of the route, I would expect:

   (setf (table <route>) <table)

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: David Golden
Subject: Re: CLOS style question
Date: 
Message-ID: <FssBb.192$HR.743@news.indigo.ie>
Kenny Tilton wrote:

 
> Subject: table
> Verb: add
> Object: route
> 
> What was the name of the function? I would have:
> 
>   table-add
>   table-remove
>   table-replace
>   table-list
>

add table route
remove table  route
replace table route

remove basket fruit


Now do you "get" generic functions?  


Your use of "self" and the example you just gave suggests to me you are
thinking in MP-OO terms.  


Come to the GF-OO side.
From: Kenny Tilton
Subject: Re: CLOS style question
Date: 
Message-ID: <JnABb.179536$ri.26087439@twister.nyc.rr.com>
David Golden wrote:

 > Kenny Tilton wrote:
 >
 >
 >
 >>Subject: table
 >>Verb: add
 >>Object: route
 >>
 >>What was the name of the function? I would have:
 >>
 >>  table-add
 >>  table-remove
 >>  table-replace
 >>  table-list
 >>
 >
 >
 > add table route
 > remove table  route
 > replace table route
 >
 > remove basket fruit
 >
 >
 > Now do you "get" generic functions?

Hardly. As coded my examples would have been:

    (tbl-add <table> <route>)

...so you have offered nothing new. And in your examples the table is 
still the only thing being operated on. Unless you think (list 'x) 
operates on 'x, in which case there is no hope for you.

This might help: given (add-to-collection pile thing), which of the 
arguments needs needs to sweat the implementation? (Hint: pile).

 >
 > Your use of "self" and the example you just gave suggests to me you are
 > thinking in MP-OO terms.
 >
 >
 > Come to the GF-OO side.

<rofl> congratulations! you are the first human alive to define 
object-oriented as something verb-oriented! (Apologies in advance if you 
did not know what the first O in OO stOOd for.)

OK, sorry, but c'mon: GF-OO? verb-oriented-object-oriented programming?! 
Can you see my confusion? Maybe not. Maybe you want to say, Exactly! OO 
is the misnomer!!

But then why does (add <x> <y>) vary massively according to the nature 
of <x> and incidentally (if at all) according to the nature of <y>? Note 
that this questions tosses aside any bias towards particular parameters. 
It simply asks, which parameter most shapes the implementation, and by 
how mucH?

I am just saying p1 is by far the thing being operated on and shaping 
the outcome. p2 may very well be of interest down the rouad, but plz 
don't think you will ever sit down with gf (XXX p1 p2) and start by 
writing methods specializing on p2).

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
David Golden wrote:

> Kenny Tilton wrote:
> 
>  
> 
>>Subject: table
>>Verb: add
>>Object: route
>>
>>What was the name of the function? I would have:
>>
>>  table-add
>>  table-remove
>>  table-replace
>>  table-list
>>
> 
> 
> add table route
> remove table  route
> replace table route
> 
> remove basket fruit
> 
> 
> Now do you "get" generic functions?  
> 
> 
> Your use of "self" and the example you just gave suggests to me you are
> thinking in MP-OO terms.  
> 
> 
> Come to the GF-OO side.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: David Golden
Subject: Re: CLOS style question
Date: 
Message-ID: <ftHBb.243$HR.861@news.indigo.ie>
Kenny Tilton wrote:



> OK, sorry, but c'mon: GF-OO? verb-oriented-object-oriented programming?!
> Can you see my confusion? Maybe not. Maybe you want to say, Exactly! OO
> is the misnomer!!
> 

Should have called you on this a bit earlier, but I wasn't quite aware
of where your problem might lie: Your confusion might well come from
thinking the first O in OO is "object-as-in-grammar"... While poetic, your
object-as-in-grammar OO usage is not the standard one.

Object-as-in-thing is the standard interpretation, as far as I know, backed
up by this lot (and my GoF book)
http://www.objectfaq.com/oofaq2/body/basics.htm#S1.1

"an object represents an individual, identifiable item, unit, or entity*,"
"Object-orientation is the use of objects and classes in analysis, design,
and programming." 

So, Object-oriented means the language is oriented towards working in terms
of little objects-as-in-thingys, and was a step up or at least sideways
from everything being a big lump of global state or encoded procedurally as
was the style at the time. 

oo:objects may be close to grammar:objects, grammar:subjects or even
grammar:verbs (languages with oo:metaobjects :-) )

 




* Aside: Entity, eh? Try one-table-per-object some time if you're doing an
OO<->RDBMS mapping.  Sounds kinda inefficient, and it is, but it means
relational queries can sometimes make much more sense-  consider the
rows in the table to be the set of all possible states of the corresponding
single object and it all falls into place. 




 
From: Ingvar Mattsson
Subject: Re: CLOS style question
Date: 
Message-ID: <878yllc877.fsf@gruk.tech.ensign.ftech.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> Ingvar Mattsson wrote:
> 
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>Kent M Pitman wrote:
> >>
> >>>Kenny Tilton <·······@nyc.rr.com> writes:
> >>>
> >>>
> >>>>It is an extremely rare GF that does not have one parameter that  can
> >>>>be viewed as self,
> >>>
> >>>This isn't the issue.  The issue is whether that's a paradigm, the
> >>>use of
> >>>which, adds power to the frame of mind.  Thinking in terms of self is bad
> >>>for the same reason as thinking the sun revolves around the earth.  If you
> >>>make a mistake about what is central,
> >>
> >>My comment was meant to indicate that, in my experience, almost every
> >>GF has a parameter which is indeed the central focus of the method
> >>semantics. When I see "self" in the code of a GF, I am done. I know
> >>exactly what it is, as long as I know what function I am looking at
> >>(joke).
> >>
> >>I invite nay-sayers to dig into existing actual code (spare me the
> >>foo-bars) and provide examples of GFs with no such primary target. I
> >>would expect comparison or combination functions, such as > or + (only
> >>then I would not expect generics).
> > Adding a route to a table? What is more central, the route being
> > added
> > or the table it gets added to?
> 
> Subject: table
> Verb: add
> Object: route
> 
> What was the name of the function? I would have:
> 
>   table-add
>   table-remove
>   table-replace
>   table-list
> 
> Why is table central? You are changing the table, not the route. If
> the table were somehow an attribute of the route, I would expect:

No, I am making the table aware of the route. The route is the most
central, the table is "just" an implementation detail. Without the
route, the table is meaningless. With the route, the route gives the
table a meaning.

//Ingvar
-- 
When the SysAdmin answers the phone politely, say "sorry", hang up and
run awaaaaay!
	Informal advice to users at Karolinska Institutet, 1993-1994
From: james anderson
Subject: Re: CLOS style question
Date: 
Message-ID: <3FD65588.634E3F7A@setf.de>
Kenny Tilton wrote:
> 
> Personal style has nothing to do with it. A GF's semantics either do or
> do not focus on one particular parameter, no matter how
> liberal/illiberal we want to be about what revolves around what. Put
> another way, if a GF does focus on one parameter (and they all do),
> pretending it does not in the name of open-mindedness simply hides
> information.
> 
> btw, an important unspoken is that I still prefix methods with something
> that gives away the "self" being worked on. "ix-this" and "wdw-that". So
> seeing self in the signature is never ambiguous.
> 

i would be surprised to hear that there are never functions which would be
appropriately named "do-this" or "compute-that". SELF suggests an asymmetry in
the encapsulation. in a language like object-lisp it made sense: all slots of
the target instance were available as lexical variables. that distinction does
not necessarily apply to clos. method definitions sustain a continuum.

at one end, there are functions which specialize generic behaviour. things
like PRINT-OBJECT and INITIALIZE-INSTANCE. functions which concern a single
instance only, such that one need not be reminded of class distinctions among
the various lexically apparent variables, as there is exactly one. for
functions like these, it makes sense to use names like INSTANCE and OBJECT for
the parameters. SELF wouldn't be out of place here, but it's better to use the
same term as appears in the language documentation unless one wants to imply
that there was a reason to use something else.


there are also functions which either manage the "internal" state of an
instance or compute a result based on that state. in some cases the dependency
is clear. for example, when one is implemeting aggregation or abstraction.
functions which one would tend to call VIEW-SIZE, GET-VIEW-SIZE,
COMPUTE-VIEW-SIZE. as opposed to COMPUTE-SIZE, which might conceivable depend
not only on the view, but also on the context or the units. in the former
case, it makes sense to use the name VIEW. whereby specialization may well
proceed analogous to the INSTANCE case above. SELF does not help much once one
gets down into the body of the method. this is even more apparent in the
COMPUTE-SIZE case: where the dependency is ambivalent, there may be an
alternative a generic term from the application domain which better expresses
the instance's role in the particular computation, for example ITEM, DRAWABLE,
or COMPONENT, in the case of a gui domain. in particular if the computation
depends on inherited behaviour.


at the far end of the continuum are functions which concern state which is not
really "in" any of the argument values. for example stream processing
functions. in such functions it is appropriate to name the parameters to
reflect their role in the process. FROM and TO, tend to be much easier to
follow than STREAM1 and STREAM2. another example would be presentation methods
in clim, in which there is no dependnency among the presentation context, the
present object and the presentation type, any one of which could conceivably
be subject to further decomposition and entail further presentation. an
example for which i can point to code, is to be found in
http://www.setf.de/library/de/setf/utility/walker/. given the various WALK-*
functions, which of the arguments deserves SELF status?

...
From: Arthur Lemmens
Subject: Re: CLOS style question
Date: 
Message-ID: <oprzxt8ui9k6vmsw@news.xs4all.nl>
Kenny Tilton <·······@nyc.rr.com> wrote:

> I invite nay-sayers to dig into existing actual code (spare me the
> foo-bars) and provide examples of GFs with no such primary target.

Here's an example from CLIM code:

  (defmethod region-intersection ((line line) (rectangle rectangle))
    ;; Use the Cohen-Sutherland clipping Algorithm.
    <actual code snipped>)

  (defmethod region-intersection ((line-1 line) (line-2 line))
    ;; Solve the line equations.
    <actual code snipped>)

Most methods on REGION-INTERSECTION specialize on both parameters.


Another classic example is

  (defgeneric draw (form stream))

where a typical method would specialize on both the form and the stream
(no, I don't have actual code for this one).

> I would expect comparison or combination functions

I suppose you could call REGION-INTERSECTION a a comparison or combination
function. I'm not so sure about DRAW (but you're right that I don't have
any real code with DRAW-like methods).

Arthur Lemmens
From: Kenny Tilton
Subject: Re: CLOS style question
Date: 
Message-ID: <hQzBb.179353$ri.26078427@twister.nyc.rr.com>
Arthur Lemmens wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
> 
>> I invite nay-sayers to dig into existing actual code (spare me the
>> foo-bars) and provide examples of GFs with no such primary target.
> 
> 
> Here's an example from CLIM code:
> 
>  (defmethod region-intersection ((line line) (rectangle rectangle))
>    ;; Use the Cohen-Sutherland clipping Algorithm.
>    <actual code snipped>)

woo-hoo! I almost offered overlap-p as a GF in which either/any arg 
could be...uh, well, all args have equal standing. Yes, this falls under 
the, um, combination counter-example to which I freely acceded.

> 
>  (defmethod region-intersection ((line-1 line) (line-2 line))
>    ;; Solve the line equations.
>    <actual code snipped>)
> 
> Most methods on REGION-INTERSECTION specialize on both parameters.
> 
> 
> Another classic example is
> 
>  (defgeneric draw (form stream))
> 
> where a typical method would specialize on both the form and the stream
> (no, I don't have actual code for this one).

Nah, I've been there and done that. One rarely needs to sweat the 
stream, since other imaging funstions do the Right Thing. Iand they van 
do the r/t because the specific reuirements of the stream are so 
ininteresting.

Anyway, the variations called for by the form hugely dwarf those which 
/sometimes/ are required by the stream. It is really night and day, 
which is why the form always comes first, as in your example.

kt



-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Alain Picard
Subject: Re: CLOS style question
Date: 
Message-ID: <878yllvvgh.fsf@memetrics.com>
Kent M Pitman <······@nhplace.com> writes:

> This isn't the issue.  The issue is whether that's a paradigm, the use of
> which, adds power to the frame of mind.  Thinking in terms of self is bad
> for the same reason as thinking the sun revolves around the earth.  If you
> make a mistake about what is central, it will lead you down the garden path
> toward making your operations way more complicated than you should.  By 
> inhibiting, to the extent you can, any notion of central focus, you remain
> open-minded to the possibility of reversing the centrality as a matter of
> personal programming style.  Since arglists are frequently published, they
> are not a good place to manifest this personal style.

Could you expand on this?  There's something I'm missing.
I thought the arglist was typically published in defgeneric,
e.g. you'd do

(in-package :vehicles)  ; to add some concreteness to all this

(defgeneric start (engine)
  (:documentation "Starts an engine in the appropriate fashion"))

;; then, hundreds of lines later, you'd have

(defmethod start ((self family-sedan))
   (when (key-engaged-p self)
      (rotate (ignition-mechanism self))
      ;; maybe more stuff...

   ))

I purposefully chose a GF with only one parameter, since I'm
trying to illustrate that the use of SELF as the naming argument
is neither non-sensical, nor mind-limiting.

In the above example, what do you think is wrong with the
arglist as published (ENGINE) and with SELF in the method?


-- 
It would be difficult to construe        Larry Wall, in  article
this as a feature.			 <·····················@netlabs.com>
From: Laurence Kramer
Subject: Re: CLOS style question
Date: 
Message-ID: <br7ahi$o9b$1@wolfberry.srv.cs.cmu.edu>
Alain Picard wrote:

> Kent M Pitman <······@nhplace.com> writes:
> 
> 
>>This isn't the issue.  The issue is whether that's a paradigm, the use of
>>which, adds power to the frame of mind.  Thinking in terms of self is bad
>>for the same reason as thinking the sun revolves around the earth.  If you
>>make a mistake about what is central, it will lead you down the garden path
>>toward making your operations way more complicated than you should.  By 
>>inhibiting, to the extent you can, any notion of central focus, you remain
>>open-minded to the possibility of reversing the centrality as a matter of
>>personal programming style.  Since arglists are frequently published, they
>>are not a good place to manifest this personal style.
> 
> 
> Could you expand on this?  There's something I'm missing.
> I thought the arglist was typically published in defgeneric,
> e.g. you'd do
> 
> (in-package :vehicles)  ; to add some concreteness to all this
> 
> (defgeneric start (engine)
>   (:documentation "Starts an engine in the appropriate fashion"))
> 
> ;; then, hundreds of lines later, you'd have
> 
> (defmethod start ((self family-sedan))
>    (when (key-engaged-p self)
>       (rotate (ignition-mechanism self))
>       ;; maybe more stuff...
> 
>    ))
> 
> I purposefully chose a GF with only one parameter, since I'm
> trying to illustrate that the use of SELF as the naming argument
> is neither non-sensical, nor mind-limiting.
> 
> In the above example, what do you think is wrong with the
> arglist as published (ENGINE) and with SELF in the method?
> 

I'm sure Kent has his own take on this, but my answer is:
Because it doesn't read like English.  You're not testing
whether the key is engaged in the "self" or accessing the
ignition mechanism of the "self."  These operators are
applied to a "sedan" and that's the way the method should
be written.

One of the beauties of Lisp (as opposed to Alogol-syntax
languages) is that it when written properly it reads almost
like English, while still maintining precision of meaning.
This makes the code self-documenting.

While it is a good practice to keep one's methods as
short as possible, sometimes even a well-written on
can run on for a good number of lines as you've elided
above.  I often find that when I'm browsing unfamiliar
code (may even be my own) to understand how something works,
and I'm near the end of a long method and run into a "self,"
I sometimes get confused as to what "self" actually is.
Maybe my short term memory has totally gone to seed,
but I'd rather see a descriptive name than a "self."

An exception to this rule are methods operating on much
more abstract constructs than sedans, where "object" or
"obj" might be appropriate.


Larry