I noticed that the method signature (according to the hyperspec) for
slot-unbound is:
------------------------------------------
slot-unbound (class t) instance slot-name
Arguments and values
class--the class of the instance
instance--the instance in which the attempt was made to read the
unbound slot
slot-name--the name of the unbound slot
result--an object.
------------------------------------------
Usually, I just write
(defmethod slot-unbound ((class t) (class-name class-name) slot)
(format t "The slot ~A in not bound." slot))
or something like that - you get the idea. Why should the signature
include (class t)? I have a feeling that I don't understand what's
really going on; shouldn't
(defmethod slot-unbound ((class-name class-name) slot) .... )
be sufficient for the generic dispatch.
Sorry, but please don't email me (too much uncleared spam).
··········@eudoramail.com (Rand Sobriquet) writes:
> I noticed that the method signature (according to the hyperspec) for
> slot-unbound is: [..]
> slot-unbound (class t) instance slot-name
In terms of method signatures, "(class t)" is precisely the same as
"class", so I think the point here is only to emphasize that this
standard method applies to all meta-classes.
> [..] shouldn't
>
> (defmethod slot-unbound ((class-name class-name) slot) .... )
>
> be sufficient for the generic dispatch.
It's quite likely useful to be able to dispatch on the meta-class,
particularly if you have specified your own meta-classes, so I think
it's very appropriate that this argument is there. If you only use
standard-classes, then of course the class argument is superfluous,
but that's obviously not a good reason not to have it there.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> wrote in message news:<··············@vserver.cs.uit.no>...
> It's quite likely useful to be able to dispatch on the meta-class,
> particularly if you have specified your own meta-classes, so I think
> it's very appropriate that this argument is there. If you only use
> standard-classes, then of course the class argument is superfluous,
> but that's obviously not a good reason not to have it there.
Frode,
Thanks for your clear explanation. I have not paid much attention to
meta-classes in the past. Though I have the AMOP book, I have not
studied it careful. My impression was that programming meta-classes
is useful only if you want to add something substantial such as a
persistent class (as Pascal mentioned earlier) or some sort of
knowledge representation ability. But, as you said, it makes alot of
sense to allow specialization on the metaclass.
Rand Sobriquet wrote:
> I noticed that the method signature (according to the hyperspec) for
> slot-unbound is:
>
> ------------------------------------------
> slot-unbound (class t) instance slot-name
>
> Arguments and values
>
> class--the class of the instance
> instance--the instance in which the attempt was made to read the
> unbound slot
> slot-name--the name of the unbound slot
> result--an object.
>
> ------------------------------------------
>
> Usually, I just write
>
> (defmethod slot-unbound ((class t) (class-name class-name) slot)
> (format t "The slot ~A in not bound." slot))
...not quite. You probably meant this:
(defmethod slot-unbound ((class t) (object class-name) slot)
...)
> or something like that - you get the idea. Why should the signature
> include (class t)? I have a feeling that I don't understand what's
> really going on; shouldn't
>
> (defmethod slot-unbound ((class-name class-name) slot) .... )
>
> be sufficient for the generic dispatch.
Again, you probably mean
(defmethod ((object class-name) slot)
...)
The class parameter is only needed when you make use of the metaobject
protocol. Otherwise, you can safely ignore the first parameter. The type
T means that you can use any type in that argument position. If you write...
(defmethod slot-unbound (class (object class-name) slot)
...)
...you will probably get an "argument not used" warning from the
compiler. One way to suppress the warning is this:
(defmethod slot-unbound (class (object class-name) slot)
(declare (ignore class))
...)
Another way is this:
(defmethod slot-unbound ((class t) (object class-name) slot)
...)
...because the compiler assumes the specialization of an argument
already as a use (which makes sense if you think more about it).
When you start to use the MOP, you may need to make more distinctions,
like this:
(defmethod slot-unbound
((class standard-class) (object ...) (slot ...))
...)
(defmethod slot-unbound
((class persistent-class) (object ...) (slot ...))
...)
If you don't understand this, then you need to read something about
metaobject protocols. It's hard to explain these things in a single
usenet posting.
However, CLOS already provides enough rope needed for most tasks. If you
need more information, you may want to explain why you want to
specialize slot-unbound. That's already unusual, IMHO...
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> The class parameter is only needed when you make use of the metaobject
> protocol. Otherwise, you can safely ignore the first parameter. The type
> T means that you can use any type in that argument position. If you
> write...
>
> (defmethod slot-unbound (class (object class-name) slot)
> ...)
>
> ...you will probably get an "argument not used" warning from the
> compiler. One way to suppress the warning is this:
I think the original question could have been interpreted this way:
Why wasn't the signature defined this way:
(defmethod slot-unbound ((class class) (object class-name) slot)
For all practical circumstances, this method would be applicable everywhere
the specified method would have been applicable. It is a reasonable question
which way it would better have been defined, although the decision has
little practical impact.
There is also an issue whether the signature might also have been specified
this way:
(defmethod slot-unbound ((class standard-class) (object class-name) slot)
The above signature acknowledges the possibility that there might be classes
that are _not_ standard-classes -- has anyone ever done this -- and it is
quesrionable whether a slot-unbound method intended for standard-class might
be capable of handling slot-unbound for my
standard-class-with-different-slots-depending-on-sixth-value-of-decode-universal-time-on-standard-time
metaclass.
(It's metaclasses like this that enable cheap restaurants to put different
prices on their web-published menus when viewed on Saturday or Sunday.)
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> [..] The above signature acknowledges the possibility that there
> might be classes that are _not_ standard-classes -- has anyone ever
> done this -- and it is quesrionable whether a slot-unbound method
> intended for standard-class might be capable of handling
> slot-unbound for my standard-class-with-different-slots-depending-
> on-sixth-value-of-decode-universal-time-on-standard-time metaclass.
I think it's very appropriate the way it is specified, because
otherwise an error that is really a an unbound-slot error could appear
as a no-applicable-method error, which would be confusing. And I don't
see how signaling an error by default could ever be inappropriate.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> "Steven M. Haflich" <·················@alum.mit.edu> writes:
>
>>[..] The above signature acknowledges the possibility that there
>>might be classes that are _not_ standard-classes -- has anyone ever
>>done this -- and it is quesrionable whether a slot-unbound method
>>intended for standard-class might be capable of handling
>>slot-unbound for my standard-class-with-different-slots-depending-
>>on-sixth-value-of-decode-universal-time-on-standard-time metaclass.
>
> I think it's very appropriate the way it is specified, because
> otherwise an error that is really a an unbound-slot error could appear
> as a no-applicable-method error, which would be confusing. And I don't
> see how signaling an error by default could ever be inappropriate.
Your position is sound, but it still leaves gaps elsewhere. If one
accepts the suggestion that slot-value use the MOP slot-value-using-class,
then there is no mandated method of that function. The MOP specified
methods only for standard-class and funcallable-standard-class. So,
a no-applicable-method error is still a possibility for slot-value
on an object of metaclass somewhere between class and standard-class.
Even if s-v-u-c has an applicable method, if that method calls
slot-unbound, _that_ could lead to a no-applicable-method.
Of course any implementation that extends slot-value-using-class to
handle metaclasses that are not standard-class would be insane not to
extend slot-missing and slot-unbound similarly. My original remark was
that the method signature for slot-unbound suggests that the system
method must be willing to handle absolutely any metaclass. (This
complicates the implementation of the obvious restarts.) If the method
instead had been specified on standard-class, the partitioning of
responsibility would have been every so slightly different. I think
this is a very subtle and interesting point in the specification of
metaobject protocols, although it has little practical impact.
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> > (defmethod slot-unbound ((class t) (class-name class-name) slot)
> > (format t "The slot ~A in not bound." slot))
>
> ...not quite. You probably meant this:
>
> (defmethod slot-unbound ((class t) (object class-name) slot)
> ...)
>
Yes, sorry, this is just a bad habit - if the method is short I just
use the name of the class for the object:
(defmethod refresh ((worksheet worksheet)) ...)
>
> If you don't understand this, then you need to read something about
> metaobject protocols. It's hard to explain these things in a single
> usenet posting.
Yes, I plan on reading more about it soon - it's just that I have not
encountered anything that I could not solve using CLOS proper.
>
> However, CLOS already provides enough rope needed for most tasks. If you
> need more information, you may want to explain why you want to
> specialize slot-unbound. That's already unusual, IMHO...
>
I was just reviewing the CLOS operators that I had never used and
playing with them to see if there was any circumstances where they
would come in handy. I thought that I could use slot-unbound perhaps
to tighten up code but then it seemed that I could accomplish the same
ends by just using well-formed :initforms.
Pascal, thanks for your answer.