[squeak-dev] opinion on xtreams wanted

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Feb 25 23:08:15 UTC 2013


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


More information about the Squeak-dev mailing list