Hi,

I have consolidated all repositories where STON code lives so that they are now all in sync, and in sync with changes from Pharo 7.

��http://ss3.gemtalksystems.com/ss/STON/
��http://smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/
��https://github.com/svenvc/ston

There are 2 CI builds

��https://travis-ci.org/svenvc/ston
��https://ci.inria.fr/pharo-contribution/job/STON/

The project's format will remain FileTree (until Tonel is supported on other Smalltalk implementations).


Last week I applied a couple of changes that I wanted to apply for a long time.

Traits are no longer used in the implementation (which should help porting to other Smalltalk implementations).

More specifically the following are used (again)

- Class>>#stonOn:
- ClassDescription>>#stonContainsSubObjects
- Metaclass>>#stonName
- Metaclass>>#stonOn:

instead of

- TClass>>#stonOn:
- TClassDescription>>#stonContainsSubObjects
- TApplyingOnClassSide>>#stonName
- TApplyingOnClassSide>>#stonOn:

use #instanceSide instead of #theNonMetaClass in MetaClass>>#stonOn:

Reorganised the packages with sub tags.

Add support for Fraction and ScaledDecimal literals (not in JSON mode). Previously a float conversion meant there was a loss of information.

Change the representation of Date to include a timezone offset (since the current Date implementation is sensitive to this).

��2018-10-11Z
��2018-10-11+00:00
��2018-10-11+02:00

A missing timezone offset is interpreted as being the local timezone offset.

Add more special representations for common value style objects. One of STON's goals is to be a human readable and human editable representation of an object graph while remaining 100% correct (not losing information). The following were added for this reason:

MimeType and URL using ZnMimeType and ZnUrl respectively as simplified values.

��MimeType['application/json']
��URL['https://pharo.org']

Color

��Color[#red]
��Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4}

FileReferences to the DiskFileSystem (effectively normal files)

��FILE['/tmp/foo.txt']

Here is an example of how much difference that makes. Given the following Dictionary

{
�� #background->Color red.
�� #workdir->'/tmp/pharo/work/' asFileReference.
�� #home->'https://pharo.org/experimental' asUrl.
�� #datatype->'application/json' asMIMEType } asDictionary

Which contains real objects as its values.

was serialised by STON BEFORE the changes as

{
�� �� �� �� #datatype : ZnMimeType {
�� �� �� �� �� �� �� �� #main : 'application',
�� �� �� �� �� �� �� �� #sub : 'json'
�� �� �� �� },
�� �� �� �� #background : Color {
�� �� �� �� �� �� �� �� #rgb : 1072693248,
�� �� �� �� �� �� �� �� #cachedDepth : 32,
�� �� �� �� �� �� �� �� #cachedBitPattern : Bitmap [
�� �� �� �� �� �� �� �� �� �� �� �� 4294901760
�� �� �� �� �� �� �� �� ],
�� �� �� �� �� �� �� �� #alpha : 255
�� �� �� �� },
�� �� �� �� #home : ZnUrl {
�� �� �� �� �� �� �� �� #scheme : #https,
�� �� �� �� �� �� �� �� #host : 'pharo.org',
�� �� �� �� �� �� �� �� #segments : OrderedCollection [
�� �� �� �� �� �� �� �� �� �� �� �� 'experimental'
�� �� �� �� �� �� �� �� ]
�� �� �� �� },
�� �� �� �� #workdir : FileReference {
�� �� �� �� �� �� �� �� #filesystem : FileSystem {
�� �� �� �� �� �� �� �� �� �� �� �� #store : MacStore {
�� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� #maxFileNameLength : 255
�� �� �� �� �� �� �� �� �� �� �� �� }
�� �� �� �� �� �� �� �� },
�� �� �� �� �� �� �� �� #path : AbsolutePath [ 'tmp', 'pharo', 'work' ]
�� �� �� �� }
}

which is 100% correct, but not very human friendly.

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.

What do you think ? Comments, feedback, remarks ?
Any other suggestions for other object that could use this treatment ?

Sven