Forums

by JensRichnow >> Wed, 4 Dec 2002 22:21:07 GMT

Hi, I just encountered a problem which puzzled me in the sense that I did not see it before I upgraded to the last consolidated patch. Or maybe it is an intended feature!? In the code snippet below the MKD has a MemberShip of Variable and is keyed on the variableName (String). Key is unique, no duplicates allowed. Now, if I try to add variables to the dict whereby the name differs in the the length of spaces, I get a 1310 (Key already used ...). I'm not sure how the key is implemented if it is a string, but I (wrongly) assumed that strings are made of characters which have a ASCII value, etc. Therefore an empty string should be different to a string containing one space which should be different to a string made of five space, etc.

Am I wrong in this assumption?

vars var1 :Variable;
var2 :Variable;
dict :VariablesByUniqueNames;
begin
app.initialiseApplication();

create dict transient;

create var1 transient;
var1.setVariableName("");
create var2 transient;
var1.setVariableName(" ");

dict.add(var1);
dict.add(var2);

app.finaliseApplication();
epilog
dict.purge();
delete dict;
end;

by cnwjre1 >> Wed, 4 Dec 2002 22:36:26 GMT

See the previous message "Heads up! Spaces in dictionary keys" from Carl Ransom on 24/4/01.
Below is the main part of the repsonse from the famous Krull McSkull ...

Now, you might still ask why does JADE implicitly trim trailing blanks on string keys in dictionary searches and should JADE continue to do so?

This 'feature' or, 'bug', call it what you will, was introduced shortly after member key dictionaries were initially implemented, and as such its existence predates the first ALPHA release of JADE. It was introduced after various feedback from "early adopters" of JADE primarily owing to observed difficulties in obtaining exact matches on string keys where the 'member key' attribute in the object contained an arbitrary number of trailing spaces. The problem was that with mkey dicts a developer didn't always have control over the significance of trailing spaces in existing string attribute values when an object was added to a mkey dict, so performing searches for an exact match using getAtKey was problematic.

I know for certain that at least some developers are aware of the implicit 'trim blanks' behaviour and that there are live applications dependent on the behaviour, so we can't just change it for everyone.

The only realistic solution to allow suppression of the implicit 'trim blanks' at this stage of the play would be to make this behaviour a string key option, similar to the 'case insensitive' option, with a default to current behaviour.

Any other feedback on this issue is most welcome.

cheers
kRuLL

by JensRichnow >> Wed, 4 Dec 2002 23:22:30 GMT

Sorry for missing the prvious thread on this topic. I guess the only option at this stage is to accept the default and intended behaviour of the MDK imlementation in Jade.

I would have thought that dictionary implementations are 'impartial' in the sense that it is up to the user/developer to maintain entries. If I intend to have no trailing or preceeding space for the key in the dictionary I would strip them BEFORE adding it to the dictionary.

And what about spaces preceding the String. They appear to be part of that String, e.g., " me" is different to " me" (tested). To me it seems an inconsistent implementation of the key.

The above suggestion of having a further option when setting up the dictionary re the treatment of spaces (preceeding and trailing) seems to be a good way (compromise).

by CarlRanson >> Thu, 5 Dec 2002 0:20:34 GMT

Yup. Basically it was a bad decision on someones part that we're now all stuck with.

by jadesupport >> Wed, 4 Dec 2002 22:36:50 GMT

Jens,

Refer the thread titled "Heads up! Spaces on dictionary keys" from 24/04/2001 further down this newsgroup.

Thanks,
Brian Johnstone,
JADE Support.