Most of the CLOS methods that I write only operate on the slots of
one object in the argument list. (And quite often, only one argument
is specialized, so it's obvious which one.) In Flavors, which did not
have multimethods, methods could merely refer to the instance variables,
without having to call SLOT-VALUE or WITH-SLOTS. If you saw a free
variable reference in the method, that was obviously an instance variable.
I never found this to be confusing. I find the need for WITH-SLOTS
on these kinds of methods to be tedious (both writing and reading),
and I hate calling SLOT-VALUE even more.
Am I alone on this? I am thinking of getting fed up after all these
years, and maybe writing a macro so that I can write code like this:
(define-simple-method increment-point ((point frob) y)
(incf x y))
Do you think you would find that very confusing?
Of course, this does not have the flexibility of doing it
the normal way. Because I don't need that most of the time.
I didn't follow the part of the standards process concerned with
the object-oriented system. I was a dyed in the wool Flavors and
New Flavors user, and then CLOS was foisted upon me. I was given
the impression that it was largely a poltical concession to Xerox,
but obviously there are some major technical advantages to CLOS.
Not having thought about this particular technicality,
there might be something really wrong with it.
But aesthetically, I didn't have a problem with it before.
(In a similar vein, everybody I know also has a simplified DEFCLASS
macro that automatically defines accessors and initforms. I think
that's a different philosophical question than the one I am raising.
Also, Flavors had some other features in the area of class mixing
and required method protocol specifications, that CLOS lacks.
I'm interested in those, too.)
And if you think I'm old-fashioned, just me thankful I'm not
suggesting that we call it DEFMETHOD1 or QDEFMETHOD*.
:)
Christopher C. Stacy wrote:
> Most of the CLOS methods that I write only operate on the slots of
> one object in the argument list. (And quite often, only one argument
> is specialized, so it's obvious which one.) In Flavors, which did not
> have multimethods, methods could merely refer to the instance variables,
> without having to call SLOT-VALUE or WITH-SLOTS.
So they were indistinguishable textually from local variables? Ick.
If you saw a free
> variable reference in the method, that was obviously an instance variable.
> I never found this to be confusing. I find the need for WITH-SLOTS
> on these kinds of methods to be tedious (both writing and reading),
> and I hate calling SLOT-VALUE even more.
>
> Am I alone on this? I am thinking of getting fed up after all these
> years, and maybe writing a macro so that I can write code like this:
>
> (define-simple-method increment-point ((point frob) y)
> (incf x y))
> Christopher C. Stacy wrote:
>> I meant
>>
>> (define-simple-method increment-point ((frob point) y)
>> (incf x y))
>>
>> of course!
>>
I see no difference. either way, I would think the class frob to be
point-like. I had to cut and paste the two side by side to see the
difference.
And either way I would be confused by "(incf x y)", because I am not a
compiler. btw, increment-point changes one axis only? i'll concede that
was probably just hasty typing, but I raise it because I think it is an
important bit of noise (threw me a little, anyway).
Otherwise:
(a) I would find a more telling name than define-simple-method.
(b) Digression: something as textually ambiguous as "(incf x y)" in the
context of points (the parameter y overriding the slot y implying (I
take) "lexical trumps magical") would /still/ be grounds for summary
execution.
(c) This multiplies syntax. I must now remember that lexical Y trumps
slottish Y. Simply (as a coding convention) call the solitary
specialized instance "self" or "this" or "moi" and there there is no
need for new syntax which creates ambiguity (lexicals and slots looking
the same in code). Used consistently (and correcting the misnomer) I get:
(defmethod increment-x ((self frob) delta)
(incf (x self) delta))
..and then of course one no longer needs increment-x, frob simply has a
slot and accessor named x, and uses CL INCF to adjust it.
kt
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Christopher C. Stacy wrote:
>
> > Most of the CLOS methods that I write only operate on the slots of
> > one object in the argument list. (And quite often, only one argument
> > is specialized, so it's obvious which one.) In Flavors, which did not
> > have multimethods, methods could merely refer to the instance variables,
> > without having to call SLOT-VALUE or WITH-SLOTS.
>
> So they were indistinguishable textually from local variables? Ick.
They were variables local to all methods associated with a flavor. This
is how most OO languages work -- instance variables are automatically
available in all methods. CLOS is one of the exceptions because its
support for multimethods means that methods are not associated with any
single class.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
>>>>> On Mon, 30 Aug 2004 03:01:42 GMT, Kenny Tilton ("Kenny") writes:
Kenny> (c) This multiplies syntax. I must now remember
Kenny> that lexical Y trumps slottish Y.
My (even stupider than I intended) example points up the first issue,
which is what happens when lexical variables from the parameter list
conflict with the slots names in the class. But is having to look
at the arglist any worse than having to look at both the arglist
and the most recent WITH-SLOTS binding list?
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> Most of the CLOS methods that I write only operate on the slots of
> one object in the argument list. (And quite often, only one argument
> is specialized, so it's obvious which one.) In Flavors, which did not
> have multimethods, methods could merely refer to the instance variables,
> without having to call SLOT-VALUE or WITH-SLOTS. If you saw a free
> variable reference in the method, that was obviously an instance variable.
> I never found this to be confusing. I find the need for WITH-SLOTS
> on these kinds of methods to be tedious (both writing and reading),
> and I hate calling SLOT-VALUE even more.
>
> Am I alone on this? I am thinking of getting fed up after all these
> years, and maybe writing a macro so that I can write code like this:
>
> (define-simple-method increment-point ((point frob) y)
> (incf x y))
....
> And if you think I'm old-fashioned, just me thankful I'm not
> suggesting that we call it DEFMETHOD1 or QDEFMETHOD*.
Might I recommend CLOS* (formerly Artificial Flavors) that does just that.
In fact it uses the names defclass* and defmethod*, but what can I say,
I'm an old-fashioned guy. Just a small hack, but what's the point of
using Lisp if you can't make it work your way?
http://xenia.media.mit.edu/~mt/lisp/closstar.lisp