[Pharo-project] Xtreams vs become:

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Oct 13 15:59:31 EDT 2010

2010/10/13  <mkobetic at gmail.com>:
> 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.


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

More information about the Pharo-dev mailing list