Heads up! Spaces on dictionary keys

[ConvertFromOldNGs]

by Carl Ranson >> Tue, 24 Apr 2001 3:17:10 GMT

Hi All,

I wanted to give everyone a heads up about an jade "feature" that is not obvious.

When you have a string key in a dictionary, Jade (presumably because it knows what's best for us) will strip all trailing spaces automatically.

For instance:

Assume we have a class "Data" with a string field "name" and a dictionary "DataDict" using Data.name as its key, the following code demonstrates the problems.

showBug();
vars
dataDict : DataDict;
data : Data;begin

create dataDict transient;

create data transient; data.name := "Palm"; dataDict.add(data);
create data transient; data.name := "PalmerstonX"; dataDict.add(data);
create data transient; data.name := "Palmerston "; dataDict.add(data);

write '(' & dataDict.getAtKey('Palmerston').name & ')'; // no traling space - writes (Palmerston )
write '(' & dataDict.getAtKey('Palmerston ').name & ')'; // one traling space - returns (Palmerston )
write '(' & dataDict.getAtKey('Palmerston ').name & ')'; // three traling spaces - returns (Palmerston )

create data transient; data.name := "Palmerston"; dataDict.add(data); // !!! exception - key already used in this dictionary
end;

In short the assumption that the dictionary key will equal the data field is invalid in cases where the data field has trailing spaces. I've been told this is the intended behaviour of Jade.

Cheers,
CR

[ConvertFromOldNGs]

by krull >> Tue, 24 Apr 2001 11:40:04 GMT

Hi Carl,

Your supplied example demonstrates that JADE explicitly removes trailing blanks consistently for searches e.g. in both add and getAtKey operations.

Correct me If I'm wrong, but I suspect your example doesn't reflect what you actually want to do in your application. Typical cases that I know of were trailing blanks are significant generally involve partial key searches, where you would be using dictionary relative key access methods such as getAtKeyGeq rather than looking for an exact match with getAtKey.

If this is the case, a simple way to handle this, is to simply append a "low value" (e.g. "#01") to the search key.

Example based on your data:
Suppose your dictionary contained keys "Palmerston" and "Palmerston North" and a user wished to search for a best match on "Palmerston "

// extend example - note: in production code "#01" will become a global constant
create data transient; data.name := "Palmerston"; dataDict.add(data); create data transient; data.name := "Palmerston North"; dataDict.add(data); write '(' & dataDict.getAtKeyGeq('Palmerston' & "#01").name & ')'; // finds Palmerston
write '(' & dataDict.getAtKeyGeq('Palmerston ' & "#01").name & ')'; // finds Palmerston North

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