Hi henrik I do not understand everything you mention but let me comment. In the past and until now we used CDIF, then XML with XMI (ugly). and we stopped and built MSE as specified in the moose web site http://themoosebook.org/book/index.html#h1importingandexportingmodels to exchange models. So we have experience on that. It means that people that wanted to use Moose and connect it with their tools in any language were forced to write an MSE exporter. Which is simpler than to use XMI :) Now we do not want to force people to write a STON outputter but to reuse JSON since in any language like there is a JSON library like there is a XML library. For the Schema we are not that dull and know that the syntax is nothing when you do not have the metamodel :) <arg>18610159</arg> is the example I used to show the difference between form and contents when I asked people to get my birth date out of this wonderfully readable <arg> node :). So we have the meta model it is Famix. The point is not for us to port STON to Java, Ada, C#, ... . The point is that people out there in their own language should have a JSON outputer and we want to use JSON to communicate with them. Stef On Wed, Sep 27, 2017 at 3:38 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
Stephane Ducasse-3 wrote
On Tue, Sep 26, 2017 at 1:15 PM, Sven Van Caekenberghe <
sven@
> wrote:
Stef,
On 24 Sep 2017, at 12:26, Stephane Ducasse <
stepharo.self@
> wrote:
Hi Sven
For Moose we are wondering if we can use STON to save/load models instead of MSE. - I'm sure we can :)
Now my little friends would like to kill two or three birds with the same stone :)
Would it be possible to use STON to handle cycles but to generate JSON compatible in the following sense:
Class { "id": 123, "name" : "A" }
=>
{ "id": 123, "type" : "Class", "name" : "A" }
It means that we could be able to output an extra field and when we read that the materialiser would create an entity based on the type field for example.
Am I thinking something totally wrong?
I am not sure how to answer.
It should be possible to use STON as it is, no ?
No because they want to have JSON syntax ie.
{ "id": 123, "type" : "Class", "name" : "A" }
and not
Class { "id": 123, "name" : "A" }
JSON is different, as you know. NeoJSON was not designed to work with such dynamic types, its optional mapping mechanism works with a static type map. STON is a format with an implementation, it is not designed as a general purpose object visitor.
To me STON is nearly what we need - handling cycles - nearly JSON
But else we will have to redo our own way to handle cycles again so this is why if we could avoid it would be good.
Sven
Stef
I would ask myself a second, and quite likely a third, time what JSON is supposed to give you. "It's JSON! Anyone can parse it!", is about as useful as an XML file without a defined schema. In most cases (static/non-reflective languages excluded) it'll be simpler to just port STON, compared to building an arbitrary object materializer in whatever language you intend as a target on top of a stock JSON parser. Plus, the syntax of the text files will be nicer :) (And, if you're serious about cross-language object interchange formats, there's really no way around the static type map approach, even if the on-disk format happens to be JSON)
Cheers, Henry
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html