For the load script for Xtreams in the list archive, which Frank
mentions, there is one here

    http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-September/165822.html

But it refers to a copy Colin Putney keeps at his wiresong site.

--Hannes

On 2/25/13, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 2013/2/26 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>> 2013/2/25 Colin Putney <colin at wiresong.com>:
>>>
>>>
>>>
>>> On Mon, Feb 25, 2013 at 1:52 PM, Frank Shearar <frank.shearar at gmail.com>
>>> wrote:
>>>
>>>> When I need streams, I only use Xtreams.
>>>>
>>>> (Yes, it is maintained, but it doesn't actually require much
>>>> maintenance.)
>>>
>>>
>>> +1.
>>>
>>> Xtreams is great.
>>>
>>
>> Yes, great, maintainable and maintained.
>> Compatible? it depends compatible with what...
>> It is a quite stable cross-platform library, so yes it is compatible
>> with other dialects.
>> Let me remind this link http://code.google.com/p/xtreams/ just in case.
>>
>> If you mean compatible with legacy Stream, no, this was a deliberate
>> choice.
>> I guess this is the best way to avoid importing cruft, and probably a
>> good choice.
>>
>> Now, providing a legacy Stream compatibility layer should be really
>> easy, at least for the most common selectors (ANSI).
>> Solution 1) create a new wrapper that offers the compatible API, and
>> arrange to let that wrapper on top of Xtreams composition chain.
>> Solution 2) create *LegacyStream extension messages in top category.
>
> Oops top classes, of course, I feel tired...
>
>>
>> If we wish to take this path, the best is to ask author's advice, but
>> I bet they will agree on 1).
>> I'm quite sure this discussion already took place, but I feel too lazy
>> to dig in mails this evening.
>>
>> The question is why you would wish such a compatibility thing?
>> IMO, if you're going to create a new application, it's really worth
>> trying with native Xtreams API.
>> You'll acquire different reflex/adopt different patterns.
>>
>> Replacing the whole legacy Stream hierarchy in Squeak or Pharo is
>> another matter.
>> As already told, these classes have taken many responsabilities, so
>> it's a really big work.
>> The compatibility layer might serve for a transition period if we
>> really wish to engage on this path.
>>
>> Last questions about alternatives: yes, plenty. Let's cite just two in
>> Squeak/Pharo world:
>> - Nile http://www.squeaksource.com/Nile/ : streams composed by Traits.
>> Very complete. Main drawback IMO: tried to be a replacement of legacy
>> streams, and thus failed to be simple.
>> - SqueaXtream http://www.squeaksource.com/XTream/ which is my own
>> playing with some of Xtreams ideas (composition) with Stream
>> compatible API. It's focused on Squeak and performance.
>> Frankly, you should better stick with Xtreams, it's the most solid and
>> supported.
>>
>> Nicolas
>
>