[mcclim-devel] pathname and accept

Robert P. Goldman rpgoldman at sift.info
Wed Aug 10 19:05:20 UTC 2005


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

    TM> On Aug 10, 2005, at 12:01 PM, rpgoldman at real-time.com wrote:

    >>>>>>> "TM" == Timothy Moore <moore at bricoworks.com> writes:
    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...

    TM> Ah, but  that's a quality of implementation issue. I think it would be 
    TM> completely reasonable for the command reader to do something friendly 
    TM> with these errors.  The accepting-values code does try to something 
    TM> reasonable with any error that results from accept.

A related problem is that when I tried to set up accept to do the
reprompting along the lines that I had mentioned in my earlier email,
I found that it turned the pane whence command argument values were
being read into gobbledygook --- my format string, that was supposed
to tell the user s/he had done something wrong, got echoed all over
the form for inputting values, making it unusable.  :-(

I.e., modifying the ACCEPT method for this purpose seems
inappropriate, since you don't have enough control over the context
within which ACCEPT will be invoked.

This seems to suggest that one might need to modify STREAM-ACCEPT
instead.  But that seems like a bit of a Catch-22.  That option seems
pretty much open to you only if (a) you provide a completely new
method for stream-accept or (b) you have access to the source code to
modify.

So does this mean that we have, in McCLIM, a version of ACCEPT that
doesn't provide enough of a stable context for us to extend built-in
methods?  Is the spec insufficiently strong to allow us to extend the
ACCEPT protocol without risk of breaking things?  Or have I overlooked
something (quite likely, alas)?

Best,
R




More information about the mcclim-devel mailing list