musikinformatik / JSONlib

A JSON de- and encoder for SuperCollider
GNU General Public License v2.0
11 stars 0 forks source link

What do we want to do with sc object that are keys of dictionaries? #26

Closed telephon closed 1 year ago

telephon commented 1 year ago

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.

capital-G commented 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 :)

telephon commented 1 year ago

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?

capital-G commented 1 year ago

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.

image

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?

telephon commented 1 year ago

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.

capital-G commented 1 year ago

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.

telephon commented 1 year ago

yes, I suppose that is good enough.