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