Hi Henrik, I implemented some of your suggestions and did some cleanups:
=== Name: STON-Core-SvenVanCaekenberghe.97 Author: SvenVanCaekenberghe Time: 23 October 2018, 3:32:00.595497 pm UUID: a627a421-4735-0d00-8c11-99b80be56389 Ancestors: STON-Core-SvenVanCaekenberghe.96 make #stonName a Symbol everywhere and add comments to STONReader>>#lookupClass: add an #asString conversion in STONReader>>#parseNamedInstVarsFor: to ease porting fix STONCStyleCommentsSkipStream>>#readInto:startingAt:count: and add #testBlockReading change the implementation of STONReaderError>>#messageText to ease porting === Name: STON-Tests-SvenVanCaekenberghe.90 Author: SvenVanCaekenberghe Time: 23 October 2018, 3:32:18.123909 pm UUID: 309faf22-4735-0d00-8c12-16b60be56389 Ancestors: STON-Tests-SvenVanCaekenberghe.89 make #stonName a Symbol everywhere and add comments to STONReader>>#lookupClass: add an #asString conversion in STONReader>>#parseNamedInstVarsFor: to ease porting fix STONCStyleCommentsSkipStream>>#readInto:startingAt:count: and add #testBlockReading change the implementation of STONReaderError>>#messageText to ease porting === Or https://github.com/svenvc/ston/commit/90a96aeb7042822f370e6f4cda6f1aed78457658 I still do not clearly understand the problems with ScaledDecial. If the implementation is different on the other platform, the writing and reading might need different implementations, but the general syntax, <nominator>/<denominator>[s<scale>] can remain the same, no ? Sven > On 18 Oct 2018, at 11:03, Sven Van Caekenberghe <[email protected]> wrote: > > > >> On 18 Oct 2018, at 10:59, Henrik Sperre Johansen >> <[email protected]> wrote: >> >> >> >> On Tue, Oct 16, 2018 at 9:28 PM Sven Van Caekenberghe <[email protected]> wrote: >> >> >>> On 16 Oct 2018, at 19:03, Henrik Sperre Johansen >>> <[email protected]> wrote: >> >>> - 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. >> >> >> I must be missing something, it seemed to me neither FileReference >> >> #stonOn: nor STONFileReference class >> #fromSton: actually required >> STONFileReference to be a subclass of FileReference... > > Yes, you are right, but by making it a subclass, you can infer that it > generates something that is compatible with its superclass, that was the idea. > > Anyway, it is an implementation artefact, so it is not that important. > > If you handle FILE on a platform that does not have FileReference, then you > won't need it. You would then add an #stonName equal to FILE somewhere else. > >> Cheers, >> Henry
