Closed telephon closed 1 year ago
I don't consider this an issue as the JSON standard is sparse but quite specific about e.g. key layout and for me the goal of this lib should be to parse and generate valid, exchangeable JSON with other applications and not a transparency of SCs dictionary implementation.
Its like casting a float to an integer and then convert it to a float again. There are circumventions to prevent information loss but at the same time an integer casting seems not to be the proper tool for the job :)
Ok, yes. I only wondered because we are converting the values, so there is a hidden assumption that keys are always strings or symbols. This assumption, I suppose, is in JSON, right?
We are converting them because JSON only allows strings as keys, see https://www.json.org/json-en.html
JSON is built on two structures:
- A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
- An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.
... An object is an unordered set of name/value pairs. An object begins with {left brace and ends with }right brace. Each name is followed by :colon and the name/value pairs are separated by ,comma.
The other possibility would be to just drop them (too implicit for my taste) or raise an exception (not a common workflow in sclang).
What would be your suggestion for this case?
We can keep it as it is.
My idea would have been to add an instance variable next to <>useEvents, called <>convertKeys
(false by default) and then write:
{ v.isKindOf(Dictionary) } {
if(useEvent) {
res = Event.new;
v.pairsDo { |key, x|
var key = if(convertKeys) { this.prConvertToSC(key) } { key.asSymbol };
res.put(key, this.prConvertToSC(x));
};
res;
} {
v.collect { |x| this.prConvertToSC(x) }
}
}
But I am not sure if we need this.
I think we should simply stick to the json syntax here? I never came around casting the key strings to something else (most likely a number? - in which case you should maybe reconsider your JSON layout). I would think differently if we would throw away any kind of additional (type) information, but this is not the case here.
Maybe it would be good to add documentation that there exists a private method which can convert strings to sc objects? At the same time, I think the people who need this kind of functionality look at the source code anyway.
yes, I suppose that is good enough.
A good example is
(2: "hello", 1: "word")
– this won't be reconverted to itself, but to('2': "hello", '1': "word")
. Similarly, dictionaries that have parseable keys, like arrays of strings.This is not a big issue, just saying.