I've tested this strategy, and it works well:
- use accessors self input/self output instead of inst. var.
- lazily initialize the input for Collection and File
In collection tests, I have used
^input ifNil:[input := outer terminal reading]
where: outer := output := collection writing.
This is because some Block transforms can't access the terminal collection...
I have a bug with File though - it looks like double closing. The
symptoms are that no file can't be further opened untill we quit the
image...
Nicolas
2010/10/15 Nicolas Cellier <[email protected]>:
> 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
