[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] parameter case sensitivity
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] parameter case sensitivity |
Date: |
Sun, 6 Nov 2016 20:03:11 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hi Al.
On Sun, Nov 06, 2016 at 12:55:02PM -0500, al davis wrote:
> I am thinking a new kind of character .. call it "Ichar". It's just
> like a "char" except for the compare functions.
> [..]
> // with a case-sensitivity switch
> bool less(a,b){
> return (!OPT::case_insensitive && tolower(a)==tolower(b))
> ? a<b : tolower(a)<tolower(b); }
>
> Now use it everywhere.
>
> Once that is done, all those "if (insensitive)" can be stripped.
this looks equivalent to what i did, except it's more elegant.
> We need to think of "what-if's" regarding switching modes, to make sure
> it makes sense.
>
> The issues:
>
> 1. Parameter is defined case-sensitive, then used insensitive.
> This one seems easy at first, but what about duplicates?
tell about duplicates via error()? this will not be possible with IChar
and less alone. my current approach uses a DICT class to wrap the map,
would that be a good place?
> 2. Parameter is defined insensitive, then used sensitive.
> Does storage preserve case?
> Does it become sensitive after initial storage?
> or does this word become insensitive forever?
interesting thought. "sensitive after initial storage" is what the
proposed solutions do.
an alternative "insensitive forever" might look like
hypothetical gnucap> insensitive on
hypothetical gnucap> parameter answeR=42
hypothetical gnucap> insensitive off
hypothetical gnucap> eval Answer
Answer=42 // !!
i have no clue how to do that (efficiently, elegantly etc.). and it
might get confusing here
hypothetical gnucap> parameter AnsweR=43
hypothetical gnucap> eval answeR
...
there are reasons for both, 42 and 43. but do you see a use case?
my uneducated preference is "sensitive after initial storage", without
extra tolower or toupper in insensitive mode. FTR it will produce
hypothetical gnucap> insensitive on
hypothetical gnucap> parameter answeR=42
hypothetical gnucap> insensitive off
hypothetical gnucap> eval Answer
Answer=Answer // it's not there, (no surprise)
> 3. Remember, it's not just parameters.
indeed, i have DICT under parameters, under the dispatcher and for
nodemaps in the draft i pushed earlier today. there's more i could use
it for (e.g. insensitive madness in gnucap-adms parameters...).
thanks!
felix