Hello,
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.
That’s what I guessed to be the reason of this feature. :-)
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
Tell me if you need help to implement this feature, I’ll be happy to contribute! :-)
Cheers, Julien
---
Julien Delplanque
Doctorant à l’Université de Lille Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 |
