[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?
I could imagine trying to create a new presentation subtype of pathname that would meet this constraint.
But doesn't it seem that it would have been reasonable to make a pathname a compound type that would allow for constraints?
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 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?
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?
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.
Thanks, Robert
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
On Aug 10, 2005, at 11:31 AM, Timothy Moore wrote:
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
I should mention that this section is erroneously called "Signaling Errors inside present methods." This errors are designed to be signaled inside of accept methods!
Tim
"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
On Aug 10, 2005, at 12:01 PM, rpgoldman@real-time.com wrote:
"TM" == Timothy Moore moore@bricoworks.com writes:
TM> See 24.3 in the Input Editing chapter which describes theconditions 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...
Ah, but that's a quality of implementation issue. I think it would be completely reasonable for the command reader to do something friendly with these errors. The accepting-values code does try to something reasonable with any error that results from accept.
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. :-(
Yup.
Tim
"TM" == Timothy Moore moore@bricoworks.com writes:
TM> On Aug 10, 2005, at 12:01 PM, rpgoldman@real-time.com wrote:
>>>>>>> "TM" == Timothy Moore moore@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
-
Robert P. Goldman -
rpgoldman＠real-time.com -
Timothy Moore