Porting the newest version (0.96 from ss3), a few comments: - Date in other dialects (and VA specifically) do not contain tz offset - the roundtrip will thus necessarily be lossy. I chose to truncate the TZ info on import, and write without any when storing. In other words, if unknown, treat the dates as if they are in local tz from the PoV of STON.
This will obviously cause some discrepancies if transferring dates from one dialect to another, but AFAICT, that's already the case when doing Pharo -> Pharo transfer between systems in different timezones with tz info omitted. - STONFileReference is a subclass of FileReference, this could/should be Object, right? - STONFileReference >> #stonName and the other new implentors return a string, while the existing implentors return a symbol. Not a big deal for Pharo, but for others, it would be nice if they were consistent. - Is STONCStyleCommentsSkipStream >> #readInto:startingAt:count: in use, but untested? It contains a reference to self encoder which seems to not be implemented. - ScaledDecimals have different internal representations in different dialects*. numerator/denominator aren't always implemented in terms of interpretation as a fraction; explicitly converting to fraction before printing numerator / denominator in STONWriter >> #writeScaledDecimal: would be of help in keeping the code cross-platform compatible. By contrast, implementing newFromNumber:scale: for STONReader is much less likely to cause clashes with existing functionality. - From a cross-dialect perspective, ZnMimeType, ZnUrl, and (to an extent) FileReference extensions feel like they don't really belong in core, but I have no better suggestion of how to package them in an easily loadable manner :/ The stonName definition split used for STONFileReference seems like a good thing from this PoV; maybe the same could be done for MimeType and Url? Then you can load core, ignore the extensions on missing classes, but still have classes in the image implying you might want to map the custom core STON tags. * ScaledDecimals will thus also experience precision loss (like Dates) when doing dialect-roundtrips. For instance, in VAST, it stores an integer with a fixed precision and scale; 3/7s3 will come back as 429/1000s3 Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
