Hi, thanks for replying! I can share some ideas. > On Dec 23, 2015, at 12:09 AM, Sven Van Caekenberghe <[email protected]> wrote: > > Hi, > > NeoJSON does have a bit of a split personality.
Yes, this is what I noticed. Apart from this, I think it’s an awesome library, and I thank you a lot for making it. It might be good to not make a distinction between #nextAs: and #next, and only rely on #nextAs:. Then #next might be rewritten as such: NeoJSONReader>>next ^ self nextAs: self mapClass Don’t know if that makes sense or not. It might alleviate this split personality, as you put it. > When you use mappings and #nextAs: it tries to map a static type structure on > what is coming in. As such it is not really prepared for dynamic surprises > like objects being replaced by null. Yes, in the general case, once you’ve sent #nextAs: to the reader with your value schema, you’re “stuck” with that exact schema. While working on the bindings for the GitHub API, there are some JSON representations which send a “type” field (e.g. “type” : “commit”). I would like it to be possible to change the class schema to that of a subclass of the original class when detecting a combination of fields. That is, I specify a combination of fields, and if any is present, then change the class of the current object to a subclass. By specifying combinations of fields, you don't rely on the order in which they appear in the JSON. Maybe in this way it is possible to accomplish without giving up the nice property of NeoJSON not making intermediate structures? Sounds tough to do without turning it into a hack though.. > Do also note that the typing info is totally absent from the JSON itself, > unlike STON for example. NeoJSON also tries (and succeeds) in maintaining a > stream based parser that does not generate intermediate structures except > your own domain models. > > But your request does make sense and I will think about it. It might be > possible. It has been a while that I really thought about the implementation. Alright, I’m willing to help if needed. We can discuss in this e-mail thread.
