[mcclim-devel] pathname and accept

[Timothy Moore]

On Aug 10, 2005, at 10:57 AM, rpgoldman at 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