Hi !
I was reading chapter 5 of Keene (Controlling the generic dispatch), and I
found very awkward the need for specifying the name of the method combination
type as a qualifier to primary defmethod's (contrary to the standard case
which doesn't require "standard" to appear).
Also, if you have to specify explicitely the non-standard MCT, it seems even
more awkward that around-methods are specified just with :around, that is,
just like for the standard MTC.
Is there a good reason for this, not explained in the book, or is it again a
standardization artefact ?
Thanks
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> Hi !
>
> I was reading chapter 5 of Keene (Controlling the generic dispatch), and I
> found very awkward the need for specifying the name of the method combination
> type as a qualifier to primary defmethod's (contrary to the standard case
> which doesn't require "standard" to appear).
>
> Also, if you have to specify explicitely the non-standard MCT, it seems even
> more awkward that around-methods are specified just with :around, that is,
> just like for the standard MTC.
>
> Is there a good reason for this, not explained in the book, or is it again a
> standardization artefact ?
It is very likely that a primary method in the standard method
combination and a method in another method combination have different
method bodies. For example, in the standard method combination, you have
to use 'call-next-method to ensure that the method of a superclass is
called, like this:
(defmethod m (...)
(call-next-method)
(print 'foo)
...whereas in a 'progn method combination you don't, so the method below
would be (roughly) equivalent:
(defmethod m progn (...)
(print 'foo))
On the other hand, it is not possible (at least not in a straightforward
way) to suppress calling some of the applicable methods in a 'progn
method combination while in the standard method combination you just
don't call 'call-next-method in order to suppress invocation of the
methods applicable to superclasses. (There are a few simplifications
made in this description, but it's a good approximation.)
Therefore, when you change the method combination for a generic
function, it is _very_ likely that you will have to modify the
corresponding method bodies, and so apparently the CLOS designers
considered it appropriate that you get error messages for each method
definition in such a case.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> Therefore, when you change the method combination for a generic function, it
> is _very_ likely that you will have to modify the corresponding method
> bodies, and so apparently the CLOS designers considered it appropriate that
> you get error messages for each method definition in such a case.
Perhaps. However, unless several method combinations can coexist in
the same generic function, I'm not quite convinced by this argument. Besides,
wouldn't it be likely (maybe less, but ...) that you have to change the code
in :around methods as well ?
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>Therefore, when you change the method combination for a generic function, it
>>is _very_ likely that you will have to modify the corresponding method
>>bodies, and so apparently the CLOS designers considered it appropriate that
>>you get error messages for each method definition in such a case.
>
> Perhaps. However, unless several method combinations can coexist in
> the same generic function, I'm not quite convinced by this argument. Besides,
> wouldn't it be likely (maybe less, but ...) that you have to change the code
> in :around methods as well ?
A generic function can only have one method combination. (You probably
mean something else when you say "several method combinations can
coexist...", but it's better to be precise here.)
The role :around methods play in the various predefined method
combinations is always the same, so I don't see any issues here. It's a
good idea to make :before, :after and :around behave the same as in the
standard method combination (if appropriate at all) when you provide
your own user-defined method combinations.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> A generic function can only have one method combination. (You probably mean
> something else when you say "several method combinations can coexist...",
> but it's better to be precise here.)
What I meant was: maybe one could create several method combinations
for the same generic function (knowing that only one can be active at a time),
and then you would have the ability to specify which one you want to use at
method-calling time. That was just a random thought; I was wondering if such a
mechanism existed, without having any particular use for it in mind.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>>A generic function can only have one method combination. (You probably mean
>>something else when you say "several method combinations can coexist...",
>>but it's better to be precise here.)
>
> What I meant was: maybe one could create several method combinations
> for the same generic function (knowing that only one can be active at a time),
> and then you would have the ability to specify which one you want to use at
> method-calling time. That was just a random thought; I was wondering if such a
> mechanism existed, without having any particular use for it in mind.
You can do this for your own method combinations, so I don't think
there's a problem there. Check out define-method-combination - it's a
little hard to grasp the specification, but using it is not overly
complicated because you can usually pick one of the examples in the
HyperSpec and change it to your needs.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Bourguignon <····@mouse-potato.com> wrote:
> Didier Verna <······@lrde.epita.fr> writes:
>> Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
>
> Fatal error: Cannot redeclare lecture() (previously declared in /home/ghost/prof/didier/www/comp/lectures/afp.php:13) in /home/ghost/prof/didier/www/comp/lectures/.overloads.php on line 19
Thanks.
> Puis-je sugg�rer UncommonWeb? http://www.cliki.net/UCW
You can always suggest it. However, if I ever get or need (time) to
learn yet another web developement tool one day, I would choose something that
is properly documented (read: that has a real user manual) in order for the
learing phase to be as short as possible. UCW doesn't give me that impression.
http://common-lisp.net/project/ucw/documentation.html says:
Definitive documentation = Source code (!!)
Other: slides, a video, an introduction (DRAFT) (!!)
UCW is probably a good thing since I've heard about it many times. But yuck,
doesn't feel like trying...
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org