> On 26 Feb 2019, at 22:23, Esteban Maringolo <emaring...@gmail.com> wrote:
>
> El mar., 26 feb. 2019 a las 17:57, Sven Van Caekenberghe
> (<s...@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!
