On Aug 10, 2005, at 10:57 AM, rpgoldman@real-time.com wrote:
[Apologies if this is a dumb question...]
AFAICT there's no way for me to try to ACCEPT a pathname that is constrained to refer to a file that already exists. Is this true?
Yes.
I could imagine trying to create a new presentation subtype of pathname that would meet this constraint.
Yes.
But doesn't it seem that it would have been reasonable to make a pathname a compound type that would allow for constraints?
Maybe, but the CLIM presentation types are close analogues to the Common Lisp types.
Also, I have been looking at the Allegro CLIM UG and the CLIM 2 spec, and I have not been able to determine what sort of guarantees ACCEPT provides. When it reads one of my previously-existing pathnames, for example, will it be obligated to run presentation-typep at some point to check that the filename is actually previously-extant? Or is it allowed to just hope that the user has typed in a string that refers to a previously-existing filename, instead of the name of his grandmother's dog?
I believe that the user (programmer) has the freedom to pair any object with any presentation type in a presentation; if that breaks other code, then that's his problem. If an application needs a strong guarantee that the user (user) enters a valid object for a presentation type then the accept method should check that before returning.
I don't know exactly how to test this, but my rudimentary tests with trace seem to indicate that ACCEPT isn't doing any verification. Is that right?
Yes.
If so, and I want to enforce this constraint, should I be making an :around method for accept that will check the constraint and either return if it's satisfied, or invoke call-next-method if it's violated?
That's one way to do it. Be sure to return all the values returned by the primary presentation method. You could also call accept recursively from the accept method for your type.
I would have thought that there would have been some protocol for bad input (e.g., raise a particular exceptionq), but my cursory examination of the spec doesn't reveal any such.
See 24.3 in the Input Editing chapter which describes the conditions SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE.
Tim