[Pharo-project] Xtreams vs become:

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Oct 15 03:13:53 EDT 2010


Or maybe I have something simple enough :

1) let setUp initialize the output but not the input
2) access input via a message send and lazy initialization
For example, in collection tests, this would be
input
    ^input ifNil:[input := output conclusion reading]
in file tests:
    ^input ifNil:[input := file reading]

What do you think ?

Nicolas

2010/10/13 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 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.
>
> Nicolas
>
>> _______________________________________________
>> 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