Re: Ambiguous keyword abbreviation error [message #55808 is a reply to message #55805] |
Wed, 12 September 2007 08:07   |
Conor
Messages: 138 Registered: February 2007
|
Senior Member |
|
|
This bug always annoys me (well, I guess it's a feature, not a bug,
but that's how I see it). For instance, in a lot of my programs I
like to use the keyword /s for silent. Unfortunately, since it is a
one-letter keyword, once I've declared it I can't use anyother
keywords that start with the letter 's'. I find this to be highly
irritating. You would think that since the keyword I'm using exactly
matches an actual keyword, IDL could figure out that I'm referencing
that keyword, rather than using an abbreviation. Oh well. At least
when you get this error, you know exactly what the problem is.
On Sep 12, 10:08 am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
> jkj wrote:
>>> I was under the
>>> mistaken notion that these were like named variables, so as long as I had
>>> unique names for each one I was good to go.
>
>> pro my_procedures, col=col, color=color
>
>> I'm thinking "column" when I use col=col and in parts of the code
>> where "color" is not also a keyword "col" works just fine, but as soon
>> as I have "col" as the beginning of another keyword IDL cannot tell
>> the two apart (because IDL does not require you to use the entire
>> keyword, only enough of it that it can be uniquely determined)... so I
>> have to at least append 1 letter (other than 'o') to "col" and use
>> something like:
>
>> pro my_procedures, coln=coln, color=color
>
> This is diverging OT into more of a style thing, but why not bite the bullet and punch out
> the extra two characters for the sake of clarity:
>
> pro my_procedures, column=column, color=color
>
> ?
>
> cheers,
>
> paulv
|
|
|