Le 18 sept. 2018 �� 16:45, Sven Van Caekenberghe <sven@stfx.eu> a ��crit :

Hi Julien,

Good and interesting point.

Your summary is correct: STON, inheriting from JSON so to speak, only knowns about integer and float numbers. All other Smalltalk numbers get converted, which results in a loss of type and precision. That might not be a perfect situation, but nobody complained so far.

If we would change it, efficiency has to be taken into account: speed/memory efficiency as well as human typing efficiency/complexity. Compatibility, especially between different Smalltalk and other object languages, is also an aspect.

Apart from the current approach, the full STON approach could be, for example for 1/3 and 1.5s2

Fraction { #numerator:1, #denominator:3 }
ScaledDecimal { #numerator:3, #denominator:2, #scale:2}

For some types, STON uses shorter notations, either using positional arguments 

Point [ 1, 2 ]
Fraction [ 1, 3 ]
ScaledFraction [ 3, 2, 2 ]

Or a string argument, when there is a clear external representation

DateAndTime [ '2018-09-18T16:39:10.325129+02:00' ]
Fraction [ '1/3' ]
ScaledFraction [ '3/2s2' ]

Of course, we could also extend the basic number parser and allow the native (stored) notation

1/3
3/2s2

Note how that last one should use the more exact #storeOn: notation, not the #printOn: 

I'll have to think about this a bit more, as I can really not choose right now.

Sven