[Pharo-dev] In-memory FileSystem write streams not being polymorphic
stephane.ducasse at inria.fr
Tue Nov 12 15:22:21 EST 2013
On Nov 12, 2013, at 2:31 PM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> It's just a matter of selecting a strategy. I've proposed two:
> A) create a wrapper class for legacy Stream compatibility selectors
> B) create extensions for Legacy Stream compatibility selectors
> My preference goes to A)
if I understand correctly I prefer A too.
Because like that we can decide to even throw away later the wrapper and a wrapper is like a clear API.
> The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: ...), otherwise we will import all the cruft in Xtream and would go back to our starting point...
> Once the minimal support written (a few hours should be enough), we should gradually switch each every legacy Stream usage -> Xtream.
> An area which require more work is those Streams that have mixed conventions (one portion is interpreted as text, another as binary).
> In theory that's easy, we just have two streams and they both wrap on a low level binary stream, but that means we have to be very cautious with buffers and caches.
> Another area of work is usage of ugly selectors like name (we try to access the file name from the Stream API, arghh). Those usages are bad and require a rewrite.
> 2013/11/12 Stéphane Ducasse <stephane.ducasse at inria.fr>
>> or of course, you start looking at porting XStreams to pharo ;), which on the long run will
>> solve many more problems. The current situation is not that satisfactory
> having experience with it and thinking about a plan for the beginning of 40 would be great.
> I know that nicolas ported XTream to pharo/squeak. Now understanding how integrate it would be nice.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev