[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keyword precedence

"J.D. Smith" <jdsmith@astro.cornell.edu> wrote in message
> .....

Whew! Thanks for that explanation, JD. I think I understand it now.

First an executive summary for David:

* IDL's current behaviour regarding precedence of explicit keywords vs those
passed through from above by inheritance is too inconsistent to be useful.
It requires the caller to know details about inheritance mechanisms further
down the chain, which is highly undesirable.

Now a few questions/comments:

> You can actually see this happening if you throw an "print,
> arg_present(color)" into KEYWORDS_PRINT_COLOR.

I did. It prints 0 in all 3 cases. What does this tell me? ARG_PRESENT is
only supposed to return 1 if a named variable is supplied. I didn't supply

> Of course, only one of these can be used, and as it
> happens, the fully by-reference variable is chosen.

This is the crux, isn't it? Could & should this design choice be changed? If
it were, would this lead to any other surprising results?

This is my main point and I could leave it there but I'll add another

I modified MGH_EXAMPLE_KEYWORDS & played with it a
bit more. I've put the modified code on the WWW page and attached it to this
message. Now the main routine accepts _EXTRA keywords from its caller. Its
usage now reflects the intention of the whole exercise better. The idea is
that we want to pass COLOR=0 through to the printing routine but let the
user override it. (I hope nobody thinks I ever actually *write* code like
"some_procedure, COLOR=0, _EXTRA={color:12}".)

You might like to try the following set of calls:

mgh_example_keywords, COLOR=12
mgh_example_keywords, COL=12

No surprises with the first one: the default value of 0 is passed through
and printed.

With the second one we get the result that's being discussed, the user's
value of 12 overrides the default and is printed except when the "reference
wrapper" is involved in the calling chain, in which case 0 is printed.

With the third one, 12 is printed in every case! My interpretation: IDL's
handling of keyword abbreviations is such that an abbreviated keyword takes
precedence over a non-abbreviated one, and this overrides the "fully
by-reference first" rule. Which certainly suggests that the "fully
by-reference first" rule is not cast in stone.

Mark Hadfield
m.hadfield@niwa.cri.nz  http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand

begin 666 mgh_example_keywords.pro
M:&%T(&ME>7=O<F0N($9O<B!E>&%M<&QE+"!T:&4@8V%L;#H-"CL-"CL@(" @
M(" @4$Q/5"P@82P@8BP@0T],3U(@/2!C;VQO<BP@7T585%)!(#T@>T-/3$]2
M.B Q,GT-"CL-"CL@("!S<&5C:69I97,@82!C;VQO<B!I;F1E>"!O9B Q,B!T
M3" U+C(N(%1E<W1I;F<-"CL@=&AI<R!W:71H($E$3" U+C,@22!F:6YD('1H
M(&YO= T*.R!F;W(@=&AE(&]N92!T:&%T('5S97,@<F5F97)E;F-E(&EN:&5R
M;W(L($-/3$]2/6-O;&]R+"!?15A44D$]97AT<F$-"@T*(" @(&UE<W-A9V4L
M("]I;F9O<FTL("=#3TQ/4B!I<R G("L@<W1R=')I;2AC;VQO<BPR*0T*#0IE
M(%]%6%1203UE>'1R80T*#0H@(" @;65S<V%G92P@+VEN9F]R;2P@)U!A<W-I
M;F<@86QO;F<@15A44D$@:V5Y=V]R9',@:6X@<W1R=6-T=7)E.B G("L@<W1R
M:6YG*&5X=')A+" O4%))3E0I#0H@(" @;6=H7V5X86UP;&5?:V5Y=V]R9'-?
M/65X=')A#0H-"B @("!M97-S86=E+" O:6YF;W)M+" G4&%S<VEN9R!A;&]N
M<F$L("]04DE.5"D-"B @("!M9VA?97AA;7!L95]K97EW;W)D<U]P<FEN=%]C
M;VQO<BP@7T585%)!/65X=')A#0H-"F5N9 T*#0IP<F\@;6=H7V5X86UP;&5?
M:V5Y=V]R9',L(%]%6%1203UE>'1R80T*#0H@(" @;65S<V%G92P@+TE.1D]2
M32P@)T-A;&QI;F<@8V]L;W(M<')I;G0@<F]U=&EN92!D:7)E8W1L>2<-"B @
M7T585%)!/65X=')A#0H-"B @("!M97-S86=E+" O24Y&3U)-+" G0V%L;&EN
M9R!C;VQO<BUP<FEN="!R;W5T:6YE('9I82!V86QU92!W<F%P<&5R)PT*(" @
M(&UG:%]E>&%M<&QE7VME>7=O<F1S7W9A;'5E7W=R87!P97(L($-/3$]2/3 L
M(%]%6%1203UE>'1R80T*#0H@(" @;65S<V%G92P@+TE.1D]232P@)T-A;&QI
M#0H@(" @;6=H7V5X86UP;&5?:V5Y=V]R9'-?<F5F97)E;F-E7W=R87!P97(L
A($-/3$]2/3 L(%]%6%1203UE>'1R80T*#0IE;F0-"@T*