[Pharo-users] NeoJSON mapping question

Sven Van Caekenberghe sven at stfx.eu
Tue Feb 26 17:19:44 EST 2019



> On 26 Feb 2019, at 22:23, Esteban Maringolo <emaringolo at gmail.com> wrote:
> 
> El mar., 26 feb. 2019 a las 17:57, Sven Van Caekenberghe
> (<sven at stfx.eu>) escribió:
> 
>> PS: Note also that mappings can live on the class side (where they are global), but also inside specific NeoJSONReader instances (where they are local), like here.
> 
> This postscript should be a whole section in the docs, I remember it
> took me some time to fully understand this, and how flexible this
> could be.
> 
> Also I found confusing the semantics of the selectors and variable for
> mapping/mapper, because it is the `mapping` that adds a new mapping
> (e.g. #mapAccessor:).
> But this might be just me.

Well, terminology is hard, to come up with, to communicate, etc. I certainly don't think that the situation is perfect.

Both a reader and a writer are a mapper, because they (might) need to convert to/from types called schemas. (They might not need it if they only use Arrays and Dictionaries).

A schema is either a real class name, or just an abstract name to refer to (that last use is more for reading, like ArrayOfPoints, because the concept of a typed collection does not exist in Pharo, although there is also #nextPut:as:).

When you map a schema, you describe how it is read/written. You do that either with a very general block (custom mapping) or according to the common Pharo model (object mapping: a Pharo object/class with named properties).

In that last case, there is indeed a second level of mapping: that of the properties making up the object/class. Here you find mapAccessors, mapInstVars, etc (see the protocol mapping & convenience of NeoJSONObjectMapping).

A key issue is that (especially when reading) schema/type information must be passed along (again because the concept of type of an instance variable does not exist in Pharo). Especially collections are hard to map.

Some JSON is very dynamic in nature and does not follow a strict static structure of types.

> Regards!




More information about the Pharo-users mailing list