On 12 Oct 2018, at 11:49, Guillermo Polito <guillermopolito@gmail.com> wrote:
Thanks Sven :)
On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe <sven@stfx.eu> wrote: Now, AFTER the changes, the STON serialisation looks as follows:
{ #datatype : MimeType [ 'application/json' ], #background : Color [ #red ], #home : URL [ 'https://pharo.org/experimental' ], #workdir : FILE [ '/tmp/pharo/work' ] }
which is a huge improvement, IMO.
Yes, I've suffered the things you explain before :)
What do you think ? Comments, feedback, remarks ? Any other suggestions for other object that could use this treatment ?
Question: is it a new mechanism or it is based on the existing mapping mechanisms? Can we override it/extend it?
This is using the existing mechanism (with specific #stonName's that differ from the class name). Several class already used this mechanism (the Chronology classes for example). In the case of FileReference it is a bit more of a hack: FileReferences to other filesystems than disk are serialised as before. Furthermore I had to use FILE instead of File since that class already exists. On other platforms, other concrete classes might handle the same tags. It wouldn't hurt if others thought a bit about this too. In any case, I intend to work a bit on documentation later on.