Comments (8)
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.
from corto.
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.
from corto.
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.
from corto.
Moved to alpha 0.2.0 as this is QA related.
from corto.
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).
from corto.
👍
Maybe I should look back where I needed to serialize state and attributes and consume use the __str function (cx_bitmask__str
?) instead.
from corto.
Use cx_attr__str
and cx_state__str
.
from corto.
Thanks!
from corto.
Related Issues (20)
- Don't create objects when serializing between content types
- Add C++ template functions for enabling compile-time type safety
- Incorrect Environment Variables causing Installation Failure
- Serializer framework should support relative object identifiers
- Enable selecting/subscribing for unknown objects
- Add a strict option for serializers
- Add support for lazy evaluation of references HOT 1
- Add option to disable alignment of existing objects to subscribers
- Recursive query on a mount from parent of mountpoint produces incorrect results
- Standalone deployment mode
- Not providing initial '/' in type filter works for corto_select, but not for corto_subscribe filter
- Implement by-value and by-reference semantics in corto_value API
- Aliasing a member from a non-hidden base class does not fail until code generation
- Create API for determining initializer order of members HOT 1
- Support dot notation for resolving objects
- Corto observer invalid when notifying during shutdown
- Add support for objective state, observable/optional members to corto_rw API
- Primitive reference type crashes corto_value_binaryOp HOT 2
- Add support for singleton members
- How can the Corto team ease the learning curve for new users?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from corto.