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 ((p point) 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*.
:)
······@news.dtpq.com (Christopher C. Stacy) writes:
> 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.)
Wow. I often have interdependent behaviors somewhere in my systems. Even
AMOP provides for that, which is quite useful at times. It's not the
most common case, but it does happen regularly, when dealing with more
complex inheritance structures. I believe that when I get around to
writing DefDoc's html-with-css output-engine, I'll need such methods.
> (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.
Yes. I used to do this, but it ended up being more hassle than it was
worth. I usually end up using the full generality of DEFCLASS anyway, so
any wrapper around it just gets in the way. The most common thing is
that the accessor and slot name are the same symbol, but I may not want
an accessor: sometimes just a reader, sometimes no abstracted interface
to the slot's value (latter case is very rare, tho). I wouldn't gain
much other than forcing code readers to learn a new syntax if I made my
own wrapper for this single option and single removal of repetition.
> 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.)
I've developed a protocols library to specify what's in a protocol and
test that classes meet the specification for the protocol(s) they are
in.
> And if you think I'm old-fashioned, just me thankful I'm not
> suggesting that we call it DEFMETHOD1 or QDEFMETHOD*.
>
> :)
Heh.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
>>>>> On Sun, 29 Aug 2004 20:57:13 -0400, Rahul Jain ("Rahul") writes:
Rahul> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> 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.)
Rahul> Wow. I often have interdependent behaviors somewhere in my systems. Even
Rahul> AMOP provides for that, which is quite useful at times. It's not the
Rahul> most common case, but it does happen regularly, when dealing with more
Rahul> complex inheritance structures. I believe that when I get around to
Rahul> writing DefDoc's html-with-css output-engine, I'll need such methods.
Well, of course. I'm just saying that there's also a lot of code
that doesn't need to do anythign that hairy.
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. 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 ((p point) y)
> (incf x y))
>
> Do you think you would find that very confusing?
Why don't you just use accessor methods?
(defmethod increment-point ((p point) y)
(incf (x p) y))
The accessor method could be named by some non-exported symbol. AFAICS,
almost all CLOS implementations provide accessor methods that are more
efficient than SLOT-VALUE, at least in the case of standard classes,
because they can essentially just inline a simple AREF with a fixed index.
Maybe I don't understand your problem...
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
>>>>> On Mon, 30 Aug 2004 03:29:08 +0200, Pascal Costanza ("Pascal") writes:
Pascal> Why don't you just use accessor methods?
Because I don't want to define a generic function called (literally) "X".
Pascal> The accessor method could be named by some non-exported symbol.
I don't want to have to do package management and say POINT:X, either.
Pascal> Maybe I don't understand your problem...
Brevity.
Christopher C. Stacy wrote:
>>>>>>On Mon, 30 Aug 2004 03:29:08 +0200, Pascal Costanza ("Pascal") writes:
>
>
> Pascal> Why don't you just use accessor methods?
>
> Because I don't want to define a generic function called (literally) "X".
OK.
> Pascal> The accessor method could be named by some non-exported symbol.
>
> I don't want to have to do package management and say POINT:X, either.
OK.
> Pascal> Maybe I don't understand your problem...
>
> Brevity.
Of course. ;)
Keep in mind that the single instance may not necessarily be the first
argument. SETF functions take the new value as the first parameter, so
the argument you want to implicitly refer to should probably be the
second parameter. (In other words, take argument-precedence-order into
account.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
······@news.dtpq.com (Christopher C. Stacy) writes:
> 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.)
That's often the case.
> 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.
I use neither. I think of class objects as `structs on steroids'. If
I want to get at a slot, I used the appropriate accessor function.
> Am I alone on this?
No, I'm sure a lot of people agree.
> 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 ((p point) y)
> (incf x y))
>
> Do you think you would find that very confusing?
I would find it a little unexpected and therefore slightly confusing.
My main concern would be fragility. In a complex system I was working
on I realized that a certain bug was caused because of a circular
dependency between slot values upon initialization of an object. The
solution was to delay computing the slot contents until it was called
for and then cache the result. This required a small tweak to the
accessor function and a rename of the slot. Because the rest of the
code *always* used the accessor function, and because accessor
function names are not automatically generated from slot names, this
was a trivial local change. I'd have been screwed had the slot name
been compiled into other code.
> (In a similar vein, everybody I know also has a simplified DEFCLASS
> macro that automatically defines accessors and initforms.
I don't. Automatically generating names interacts poorly with the
package system and often doesn't capture the abstraction you want.
The added verbosity doesn't seem to outweigh the disadvantages.
······@news.dtpq.com (Christopher C. Stacy) writes:
> 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?
No.
> 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 ((p point) y)
> (incf x y))
>
> Do you think you would find that very confusing?
Not at all. I did the same a few years ago. But I would prefer
Flavors syntax, avoiding the specialization parameter and using self
to refer to the receiver.
You can find something similar to what you propose at:
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/oop/clos/code/
> 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.
Multiple dispatch methods makes it hard to implement the Flavors
approach to access the instance variables.
Obviously, this is Lisp so we can make things interesting by inventing
a rule that says that the specialization order defines a context order
for accessing the instance variables. With this scheme, we might
have:
(defclass a ()
((s1)
(s2)))
(defclass b ()
((s2)
(s3)))
(define-simple-method foo ((x a) (y b))
(+ s1 s2 s3))
The previous definition would be translated into
(defmethod foo ((x a) (y b))
(+ (slot-value x 's1) (slot-value x 's2) (slot-value y 's3)))
Note that s2 refers to x slot and not to y slot due to the rule of
context order. Obviously, in the single dispatch case it just looks
like the Flavors approach.
We could improve on this but, to be honest, I don't really mind using
accessors :-)
Ant�nio Leit�o.
Antonio Menezes Leitao wrote:
> Obviously, this is Lisp so we can make things interesting by inventing
> a rule that says that the specialization order defines a context order
> for accessing the instance variables. With this scheme, we might
> have:
>
> (defclass a ()
> ((s1)
> (s2)))
>
> (defclass b ()
> ((s2)
> (s3)))
>
> (define-simple-method foo ((x a) (y b))
> (+ s1 s2 s3))
>
> The previous definition would be translated into
>
> (defmethod foo ((x a) (y b))
> (+ (slot-value x 's1) (slot-value x 's2) (slot-value y 's3)))
The effect would be especially "interesting" when at a later stage, the
designer of class A decides to remove slot S2. This would implicitly
change the semantics of FOO and other methods, without further notice. I
don't think that's a good idea - too much magic going on here.
Further note that this potentially makes the job harder for people
writing their own metaclasses. SLOT-VALUE could accept slot names that
are not explicitly defined in the respective classes. (But that's just
speculation, maybe it's possible to come up with a clean design that
takes MOP issues into account.)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <············@newsreader2.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
> Antonio Menezes Leitao wrote:
>
> > Obviously, this is Lisp so we can make things interesting by inventing
> > a rule that says that the specialization order defines a context order
> > for accessing the instance variables. With this scheme, we might
> > have:
> >
> > (defclass a ()
> > ((s1)
> > (s2)))
> >
> > (defclass b ()
> > ((s2)
> > (s3)))
> >
> > (define-simple-method foo ((x a) (y b))
> > (+ s1 s2 s3))
> >
> > The previous definition would be translated into
> >
> > (defmethod foo ((x a) (y b))
> > (+ (slot-value x 's1) (slot-value x 's2) (slot-value y 's3)))
>
> The effect would be especially "interesting" when at a later stage, the
> designer of class A decides to remove slot S2. This would implicitly
> change the semantics of FOO and other methods, without further notice. I
> don't think that's a good idea - too much magic going on here.
What I do in my own code to avoid this problem is to force the user to
"declare" which slots are going to be used in that method, e.g.:
(define-method (m1 (obj1 classname slot1 slot2 ...) arg1 ... argn)
... slotX ...)
This way everything remains lexically scoped.
rg
Ron Garret wrote:
> What I do in my own code to avoid this problem is to force the user to
> "declare" which slots are going to be used in that method, e.g.:
>
> (define-method (m1 (obj1 classname slot1 slot2 ...) arg1 ... argn)
> ... slotX ...)
>
> This way everything remains lexically scoped.
...but that's already very close to what you can already do in CLOS with
WITH-SLOTS, right?
(defmethod m1 ((obj1 classname) arg1 ... argn)
(with-slots (slot1 slot2 ...) obj1
... slotX ...)))
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Antonio Menezes Leitao wrote:
>
>> Obviously, this is Lisp so we can make things interesting by inventing
>> a rule that says that the specialization order defines a context order
>> for accessing the instance variables. With this scheme, we might
>> have:
>> (defclass a ()
>> ((s1)
>> (s2)))
>> (defclass b ()
>> ((s2)
>> (s3)))
>> (define-simple-method foo ((x a) (y b))
>> (+ s1 s2 s3))
>> The previous definition would be translated into
>> (defmethod foo ((x a) (y b))
>> (+ (slot-value x 's1) (slot-value x 's2) (slot-value y 's3)))
>
> The effect would be especially "interesting" when at a later stage,
> the designer of class A decides to remove slot S2. This would
> implicitly change the semantics of FOO and other methods, without
> further notice.
Sure. Isn't that interesting?
As you know, CLOS (and the MOP and AOP and ...) is full of
"interesting" features where you change one small thing in one place
and you get different semantics in lots of other places.
In this case, however, the OP asked for something that would allow
simpler access to slots for the usual case of a single dispatch
method. So, for the usual case, you shouldn't expect any problems.
OTOH, if you decide to use a different rule, e.g., forbiding
references for slots that have the same name in more than one argument
or something similar, you might not be able to specialize a method on
two arguments of the same class.
> I don't think that's a good idea - too much magic
> going on here.
As an old Flavors programmer I must say that I agree with the OP that
slot-value and with-slots are ugly. But, as I mentioned before, I
rarely use them. Accessors don't look bad and they allow much more
extensibility.
Antonio Menezes Leitao wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Antonio Menezes Leitao wrote:
>>
>>>Obviously, this is Lisp so we can make things interesting by inventing
>>>a rule that says that the specialization order defines a context order
>>>for accessing the instance variables. With this scheme, we might
>>>have:
>>>(defclass a ()
>>> ((s1)
>>> (s2)))
>>>(defclass b ()
>>> ((s2)
>>> (s3)))
>>>(define-simple-method foo ((x a) (y b))
>>> (+ s1 s2 s3))
>>>The previous definition would be translated into
>>>(defmethod foo ((x a) (y b))
>>> (+ (slot-value x 's1) (slot-value x 's2) (slot-value y 's3)))
>>
>>The effect would be especially "interesting" when at a later stage,
>>the designer of class A decides to remove slot S2. This would
>>implicitly change the semantics of FOO and other methods, without
>>further notice.
>
> Sure. Isn't that interesting?
>
> As you know, CLOS (and the MOP and AOP and ...) is full of
> "interesting" features where you change one small thing in one place
> and you get different semantics in lots of other places.
Sure, but I would be wary with language features that may lead to
hard-to-find bugs. The implicit change that s2 refers to a slot in
object x beforehand, but to a slot in object y afterwards looks too
dangerous to me. But that's only my subjective intuition. Maybe there
are good reasons why one would want such a behavior. I just don't see any.
For example, one thing in CLOS that I don't like for similar reasons is
that it doesn't support a change in specializers well enough. For
example, if you have a method defined like this:
(defmethod m (obj)
...)
...and later on you actually want _that same method_ to be specialized
on a specific class, say:
(defmethod m ((obj some-class))
...)
...CLOS will actually create another method so that you now have two
method definitions instead of one. Luckily, the MOP allows removing the
previous method from the generic function manually, but this still
doesn't reflect my thought process in such a situation.
I think your suggestion may lead to similar problems. A method
definition macro that treats free, non-special variables as slots of one
distinguished argument, together with the restriction that one is
allowed to specialize only one argument in such a macro, would cover
most cases while avoiding potential bugs of the kind I have in mind.
Because of SETF methods it shouldn't necessarily be the first argument
that can be specialized.
Maybe DEFINE-SINGLE-METHOD is a good name. (Such a macro could
automatically create the respective generic function with an appropriate
argument precedence order, in case it doesn't exist yet, or at least
signal a warning when the specialized argument isn't the first one.)
On the other hand, maybe it's just overkill to get such a macro right in
all respects, and the method definition facilities in CLOS are already
good enough.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
>>>>> On Tue, 31 Aug 2004 01:35:19 +0200, Pascal Costanza ("Pascal") writes:
Pascal> I think your suggestion may lead to similar problems. A method
Pascal> definition macro that treats free, non-special variables as slots of
Pascal> one distinguished argument, together with the restriction that one is
Pascal> allowed to specialize only one argument in such a macro, would cover
Pascal> most cases while avoiding potential bugs of the kind I have in
Pascal> mind. Because of SETF methods it shouldn't necessarily be the first
Pascal> argument that can be specialized.
I had never assumed that it would need to be the first
parameter, just the only one that was specialized.
Christopher C. Stacy wrote:
>>>>>>On Tue, 31 Aug 2004 01:35:19 +0200, Pascal Costanza ("Pascal") writes:
>
> Pascal> I think your suggestion may lead to similar problems. A method
> Pascal> definition macro that treats free, non-special variables as slots of
> Pascal> one distinguished argument, together with the restriction that one is
> Pascal> allowed to specialize only one argument in such a macro, would cover
> Pascal> most cases while avoiding potential bugs of the kind I have in
> Pascal> mind. Because of SETF methods it shouldn't necessarily be the first
> Pascal> argument that can be specialized.
>
> I had never assumed that it would need to be the first
> parameter, just the only one that was specialized.
I haven't claimed otherwise. Sorry if I have given a different impression.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> [...]
> Sure, but I would be wary with language features that may lead to
> hard-to-find bugs. The implicit change that s2 refers to a slot in
> object x beforehand, but to a slot in object y afterwards looks too
> dangerous to me. But that's only my subjective intuition. Maybe there
> are good reasons why one would want such a behavior. I just don't see
> any.
>
> For example, one thing in CLOS that I don't like for similar reasons
> is that it doesn't support a change in specializers well enough. For
> example, if you have a method defined like this:
>
> (defmethod m (obj)
> ...)
>
> ...and later on you actually want _that same method_ to be specialized
> on a specific class, say:
>
> (defmethod m ((obj some-class))
> ...)
>
> ...CLOS will actually create another method so that you now have two
> method definitions instead of one.
I think that's a different problem: current text editors for Common
Lisp do not establish a sufficiently strong colaboration with the
Common Lisp environment to allow you to relate some text fragment with
some entity in the Common Lisp environment: What makes you feel you
were making changes on _that same method_?
Ant�nio Leit�o.
Antonio Menezes Leitao wrote:
> I think that's a different problem: current text editors for Common
> Lisp do not establish a sufficiently strong colaboration with the
> Common Lisp environment to allow you to relate some text fragment with
> some entity in the Common Lisp environment: What makes you feel you
> were making changes on _that same method_?
Nothing, but that's something I would sometimes like to have.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
In article <··············@evaluator.pt>,
Antonio Menezes Leitao <··············@evaluator.pt> wrote:
> Pascal Costanza <········@web.de> writes:
>
> > [...]
> > Sure, but I would be wary with language features that may lead to
> > hard-to-find bugs. The implicit change that s2 refers to a slot in
> > object x beforehand, but to a slot in object y afterwards looks too
> > dangerous to me. But that's only my subjective intuition. Maybe there
> > are good reasons why one would want such a behavior. I just don't see
> > any.
> >
> > For example, one thing in CLOS that I don't like for similar reasons
> > is that it doesn't support a change in specializers well enough. For
> > example, if you have a method defined like this:
> >
> > (defmethod m (obj)
> > ...)
> >
> > ...and later on you actually want _that same method_ to be specialized
> > on a specific class, say:
> >
> > (defmethod m ((obj some-class))
> > ...)
> >
> > ...CLOS will actually create another method so that you now have two
> > method definitions instead of one.
>
> I think that's a different problem: current text editors for Common
> Lisp do not establish a sufficiently strong colaboration with the
> Common Lisp environment to allow you to relate some text fragment with
> some entity in the Common Lisp environment: What makes you feel you
> were making changes on _that same method_?
>
> Ant�nio Leit�o.
With an editor like LispWorks' I would do:
step 1) move cursor to the method and call M-x undefine
step 2) change method and compile it via c-sh-c