Hello,
please have a look at 23.7.1 of the CLIM 2.0 specification. In the section about DEFINE-PRESENTATION-TRANSLATOR it says:
"arglist, tester-arglist, and doc-arglist are each an argument list that must "match" the following "canonical" argument list. (object &key presentation context-type frame event window x y) In order to "match" the canonical argument list, there must be a single positional argument that corresponds to the presentation's object, and several named arguments that must match the canonical names above (using string-equal to do the comparison)."
They are defined in the same way for DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR, DEFINE-PRESENTATION-ACTION, and DEFINE-DRAG-AND-DROP-TRANSLATOR, with the only exception that the doc-arglist "includes a named (keyword) stream argument as well".
If my interpretation is correct, you have not only to use theses names *literally* (because of the STRING-EQUAL requirement), but also the empty list is not allowed and the first argument is always required and has to be (STRING-EQUAL to) OBJECT.
I added an ASSERT to beginning of CLIMI::MAKE-TRANSLATOR-LL because I've made the error earlier to try to bind the object to a symbol non-equal to OBJECT, and I've seen that there are presentation translators in beirc that just try to bind PRESENTATION. The ASSERT is:
(assert (string-equal (car translator-args) "object") () "The first parameter of the presentation translator's argument list~%has to be STRING-EQUAL to OBJECT. (See 23.7.1)")
Well, afterwards McCLIM doesn't compile anymore. There are two presentation to command translators in dialog.lisp: COM-EXIT-BUTTON and COM-ABORT-BUTTON.
After I allowed also the empty arglist it still did not compile because (at least) the presentation to command translator COM-DESCRIBE-PRESENTATION-TRANSLATOR has the list (presentation) as its arglist as well as its tester-arglist.
Personally I think the requirement that the arglists have always to be at least the list (object) (if I interpret the spec correctly) is quite odd. There are perfectly reasonable cases to have an empty list: E.g. COM-EXIT-BUTTON doesn't need the object itself. And likewise COM-DESCRIBE-PRESENTATION-TRANSLATOR doesn't need the object but only the presentation.
Why should OBJECT be bound if it isn't used at all? The way DEFINE-PRESENTATION-TRANSLATOR and its friends are specified you cannot insert a DECLARE IGNORE (or IGNORABLE), and that means you would always get style warnings on SBCL in these cases.
The "canonical" argument list should be the following in my opinion: (&key object presentation context-type frame event window x y) And also the empty list should be considered to match it.
What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as it is, and add this to a list of known but wanted nonconformances to the CLIM specification?
Bye, Max
On Sep 15, 2005, at 10:08 PM, Max-Gerd Retzlaff wrote:
Hello,
please have a look at 23.7.1 of the CLIM 2.0 specification. In the section about DEFINE-PRESENTATION-TRANSLATOR it says:
...
If my interpretation is correct, you have not only to use theses names *literally* (because of the STRING-EQUAL requirement), but also the empty list is not allowed and the first argument is always required and has to be (STRING-EQUAL to) OBJECT.
I added an ASSERT to beginning of CLIMI::MAKE-TRANSLATOR-LL because I've made the error earlier to try to bind the object to a symbol non-equal to OBJECT, and I've seen that there are presentation translators in beirc that just try to bind PRESENTATION. The ASSERT is:
...
Well, afterwards McCLIM doesn't compile anymore. There are two presentation to command translators in dialog.lisp: COM-EXIT-BUTTON and COM-ABORT-BUTTON.
...
Personally I think the requirement that the arglists have always to be at least the list (object) (if I interpret the spec correctly) is
...
The "canonical" argument list should be the following in my opinion: (&key object presentation context-type frame event window x y) And also the empty list should be considered to match it.
What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as it is, and add this to a list of known but wanted nonconformances to the CLIM specification?
I believe the code implements the description of translator arglists on page 156 of the Franz CLIM User's guide, which is the closest thing to a reasonable revision of the spec:
"An argument list that must be a subset (using STRING-EQUAL ...) of the canonical argument list: (object presentation context-type frame event window x y)"
In other words, nothing is special about object. Code written to the older definition in the Spec should be compatible with this too.
Tim
On Thu, Sep 15, 2005 at 10:43:47PM +0200, Timothy Moore wrote:
On Sep 15, 2005, at 10:08 PM, Max-Gerd Retzlaff wrote:
Personally I think the requirement that the arglists have always to be at least the list (object) (if I interpret the spec correctly) is
...
The "canonical" argument list should be the following in my opinion: (&key object presentation context-type frame event window x y) And also the empty list should be considered to match it.
What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as it is, and add this to a list of known but wanted nonconformances to the CLIM specification?
I believe the code implements the description of translator arglists on page 156 of the Franz CLIM User's guide, which is the closest thing to a reasonable revision of the spec:
"An argument list that must be a subset (using STRING-EQUAL ...) of the canonical argument list: (object presentation context-type frame event window x y)"
In other words, nothing is special about object. Code written to the older definition in the Spec should be compatible with this too.
Yes, exactly. I think it would be rather stupid to enforce the exact behaviour the specification prescribes in this case. I've also had a look at Franz' CLIM 2 User Guide earlier, as in several cases it has more reasonable definitions.
Especially in this case as conforming code to the original specification still works without a problem.
Perhaps we should add an annotation to Gilbert's version of the spec that McCLIM actually implements what Franz proposes.
Regards, Max
Max-Gerd Retzlaff m.retzlaff@gmx.net writes:
Perhaps we should add an annotation to Gilbert's version of the spec that McCLIM actually implements what Franz proposes.
And/or maybe here:
http://mcclim.cliki.net/Compliance
Paolo
-
Max-Gerd Retzlaff -
Paolo Amoroso -
Timothy Moore