Make `dbsh_stateStr` and `dbsh_attrStr` publicly available about corto

[SanderMertens]

Interesting idea. Since these functions would become of the public hyve API, I would like to broaden the discussion a little bit. Note that when I mention "API", I mean the procedures that are described in db_object.h. I have the following concerns regarding the API:

• Consistency of naming - I tried to be as consistent as possible but the API has evolved and I would like to standardize on an official naming scheme.
• Consistency of parameter passing. The API currently does not follow the rules of the C language binding. I don't particularly like this but I don't want usability to suffer, which is the primary reason for the inconsistency. I would like to have a discussion on approaches.
• Size of the API. Currently there are quite a lot of API calls and each new call increases the learning curve of the platform. The API was once very small and lean, and I would like to return to that. This could mean making some procedures private while making others more expressive (through merging procedures).

I would like methods that are able of representing the state and attributes. I don't think I would use the dbsh_stateStr and dbsh_attrStr for this. Their string formatting is specifically designed for showing in a column (as the ls-command will do in dbsh). For JSON (#16) I would like something that is a bit more descriptive. Two suggestions:

This looks like dbsh, but is more descriptive:

{
    "attributes":"scoped|writable|observable",
    "state":"valid|declared|defined"
}

This suggestion would be easier to parse for a JS script and could be easily achieved with the existing functions:

{
    "attributes":{
        "scoped":true,
        "writable":true,
        "observable":true
    },
    "state":{
        "valid":true,
        "declared":true,
        "defined":true
    }
}

The latter is a bit verbose. This could be addressed by giving keys default values, and only serialize them when they deviate.

I would prefer the approach to be consistent with the JSON serialization of bit masks, which would favor the first approach.

[SanderMertens]

To avoid paralysis through blowing each issue up into a fundamental discussion I would proceed with exposing the functions in a public header. We can decide later whether the naming conventions, string strategy etc. fits the overall design.

[jleeothon]

The above second suggestion for the JSON is very sound. I feel bad now for not reckoning that one myself first. However, if we're already delegating some parsing to the end point application logic (with type annotations), both options above sound (relatively) too verbose. Let me think through that.

[SanderMertens]

Moved to alpha 0.2.0 as this is QA related.

[SanderMertens]

I'm going to close this issue as for now I don't think it addresses a problem. It is relatively easy to translate the attributes and state to a string (with the corresponding __str functions).

[jleeothon]

👍

Maybe I should look back where I needed to serialize state and attributes and consume use the __str function (cx_bitmask__str?) instead.

[SanderMertens]

Use cx_attr__str and cx_state__str.

[jleeothon]

Thanks!