Re: defmethod print-object :around ((condition simple-condition) stream)

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...> [2011-08-02 01:38:50 +0200]:
>
>> defmethod print-object :around ((condition simple-condition) stream)
> cf. condition.lisp line 478
>> Why is it an ":around" method?
>
> Let's look at the applicable methods:
>
>> (define-condition simple-foo (simple-error) () (:report report-foo))
> SIMPLE-FOO
>
>> (compute-applicable-methods-using-classes #'print-object (list
>> (find-class 'simple-foo) (find-class 't)))
> (#<STANDARD-METHOD (#<STANDARD-CLASS SIMPLE-FOO> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD :AROUND (#<STANDARD-CLASS SIMPLE-CONDITION> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD (#<STANDARD-CLASS CONDITION> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD (#<STANDARD-CLASS STANDARD-OBJECT> #<BUILT-IN-CLASS T>)>
> )
>
> If it were a primary method instead of an around method, the result would be
>
>> (compute-applicable-methods-using-classes #'print-object (list
>> (find-class 'simple-foo) (find-class 't)))
> (#<STANDARD-METHOD (#<STANDARD-CLASS SIMPLE-FOO> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD (#<STANDARD-CLASS SIMPLE-CONDITION> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD (#<STANDARD-CLASS CONDITION> #<BUILT-IN-CLASS T>)>
>  #<STANDARD-METHOD (#<STANDARD-CLASS STANDARD-OBJECT> #<BUILT-IN-CLASS T>)>
> )
>
>> If yes, wouldn't it be better to use a regular method
>
> Indeed, it seems that if you use a primary method, the report-function of
> SIMPLE-FOO will take precedence over the printing with
>   (apply #'format stream (simple-condition-format-control condition)
>                          (simple-condition-format-arguments condition))
>
> Whereas in the current state, through :AROUND, the printing with
>   (apply #'format stream (simple-condition-format-control condition)
>                          (simple-condition-format-arguments condition))
> takes precedence over the :REPORT option of SIMPLE-FOO.

indeed I realized that, so my questions were
- was this override intentional (apparently, from the comment below, yes)
- should it be removed (apparently yes)

>> (or even a :report argument
>
> A :report argument is equivalent to a defmethod anyway, see
>   <http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_define-condition.html>

my question was whether call-next-method was permitted in :report;
apparently yes.

>> I think this would add robustness because
>> - the code becomes cleaner
>
> It would definitely be a change in behaviour. The comment "Instead we
> define a print-object method which will be executed regardless of the
> condition type's CPL" indicates that the code is meant to provide some
> specific behaviour, regarding the condition type's CPL. Only I don't
> know if that specific behaviour is the one CLHS wants.

I think it is reasonable for a user who writes
(define-condition simple-foo (simple-error) () (:report report-foo))
to be upset that report-foo is never called by clisp.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://www.PetitionOnline.com/tap12009/ http://thereligionofpeace.com
http://camera.org http://mideasttruth.com http://jihadwatch.org
To understand recursion, one has to understand recursion first.