"TM" == Timothy Moore moore@bricoworks.com writes:
TM> 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? TM> Yes. >> I could imagine trying to create a new presentation subtype of >> pathname that would meet this constraint. TM> Yes. >> >> But doesn't it seem that it would have been reasonable to make a >> pathname a compound type that would allow for constraints? TM> Maybe, but the CLIM presentation types are close analogues to the TM> 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?
TM> I believe that the user (programmer) has the freedom to pair TM> any object with any presentation type in a presentation; if TM> that breaks other code, then that's his problem. If an TM> application needs a strong guarantee that the user (user) TM> enters a valid object for a presentation type then the accept TM> method should check that before returning.
[...snip...] >> >> 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? >> TM> That's one way to do it. Be sure to return all the values TM> returned by the primary presentation method. You could also TM> call accept recursively from the accept method for your type.
Thanks, I thought CALL-NEXT-METHOD would be the most convenient way to do this, since it frees me from worrying about how to pass in the boatload of keyword arguments!
>> 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. >> TM> See 24.3 in the Input Editing chapter which describes the conditions TM> SIMPLE-PARSE-ERROR and INPUT-NOT-OF-REQUIRED-TYPE.
Thanks. I did look at those. The problem is that if I hoist an INPUT-NOT-OF-REQUIRED-TYPE error, it's just that --- an error. There is no automagical trapping to reprompt to get good input. We just throw an error at the user, which doesn't seem like a very nice thing to do...
This seems particularly bad if one has a complex command with multiple arguments. Then you go to a lot of trouble to fill out five arguments, only to find that the first one was garbage. :-(
R