[mcclim-devel] pathname and accept

[rpgoldman at real-time.com]

>>>>> "TM" == Timothy Moore <moore at bricoworks.com> writes:

    TM> 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?
    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