2010/10/13  <[email protected]>:
> Michael and I talked about this today a bit and here's what we're thinking 
> about doing.
> We're inheriting the become: behavior from the collection growing APIs in VW 
> and it doesn't make sense to work around that there. Consequently the only 
> (relevant) become: that we do in Xtreams code is the one in 
> CollectionWriteStream>>close. If we're not eliminating the become: from 
> growing then ripping it out of closing creates a strange inconsistency.
>
> At the same time nothing is preventing the Squeak port to do away with the 
> become:s altogether. After all the terminals are meant to be dialect specific 
> and so the two ports will just be different in this regard. It's probably 
> worth highlighting in the comments/docs that assuming the "become:" semantics 
> of growing makes one's code non-portable. This way one can both get the the 
> traditional behavior in VW, but at the same time Squeak doesn't have to 
> suffer unnecessarily.
>
> To remove the "become" assumption in the test suite, I'll rewrite all the 
> ReadWriteTests splitting them up into writing and reading part, which will 
> allow creating the input after writing into the output is already done. That 
> way we don't care if the collection streams use become or not. Something like:
>
> testBlah
>
>        self write: [ :output | .... ]
>                read: [ :input | ... ]
>
> Good enough ?
>

Seems fair to me.

Nicolas

> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to