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/90a96aeb7042822f370e6f4cda6f1aed784576... 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 <sven@stfx.eu> wrote:
On 18 Oct 2018, at 10:59, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On Tue, Oct 16, 2018 at 9:28 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 16 Oct 2018, at 19:03, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> 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