> On 16 Oct 2018, at 19:03, Henrik Sperre Johansen
> <[email protected]> wrote:
>
> 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.
If you have a Date without a TZ (or better an implicit one), that would be one
strategy: write out without TZ info, drop all TZ info on read. Another option
would be to add a Z (for UTC), but that would also not be 100% correct. It
feels as if a TZ context is necessary after all.
> 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.
These are interesting questions that I have to think more about. The first goal
of STON is to be 100% when going from Smalltalk objects to STON and back. Being
cross platform or cross version is nice and important, but not a main goal, nor
is it solvable I think.
> - STONFileReference is a subclass of FileReference, this could/should be
> Object, right?
Uhh, no, since it acts as a facade that creates FileReferences.
But I can see how that would be hard to port, I guess this has to be
implemented differently in your case.
> - 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.
Yes, I'll check and try to make it consistent, you are right about that.
> - Is STONCStyleCommentsSkipStream >> #readInto:startingAt:count: in use, but
> untested? It contains a reference to self encoder which seems to not be
> implemented.
A copy/paste error, I am sure. I'll check.
> - 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.
Again, if a dialect does not implement certain classes/types, they have to be
skipped.
In terms of code organisation, separate packages could help.
An the other hand, there could be dummy objects that just hold the external
representation.
I.e. if there is no URL class, just wrap the string/text.
This would maintain some compatibility/portability.
Thx again for the feedback !
> * 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
>
