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 <[email protected]>:
> 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