[Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)

Igor Stasenko siguctua at gmail.com
Fri Oct 8 17:18:28 EDT 2010


On 8 October 2010 23:13, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/10/8 Igor Stasenko <siguctua at gmail.com>:
>> I recalled one detail:
>>
>> VW Xtreams are composable from the beginning, its a core stream feature.
>> Not like ours, which require wrappers, which i added (and thus a lot
>> of clutter on proxying message sends).
>>
>> :)
>>
>>
>
> I still fail to see the difference. Squeak_XTream are composable from
> the beginning, ReadXtream all have a source, WriteXtream all have a
> destination, and most of the subclasses fill those ivars with another
> XTream.
>
> VW_XTream.ReadStream>> on: aSource
>    source := aSource
>
> Squeak_Xtream.ReadXtream>>source: anObject
>    "Set the source of this stream"
>
>    source := anObject
>
> Or is it just a question of naming ?
> I adopted #source:, simply because #on: is harder to trace (too many
> implementors).
> Maybe the difference is just a convenient wrapping message or two
> missing in Squeak_XTream.
>
> The wrapper class you added are indeed unecessary in both
> Squeak_XTream and VW_Xtream. I should have given more feedback to you.
>
> If you want to look at differences between the two implementation,
> rather look at VW_Xtream.Buffer and subclasses.
> Also look at use of Exception handling in VW_Xtream (users of Incomplete).
> Don't look number of classes & methods, I obviously don't scale ;)
> Having only nights and week-ends left for programming, I just don't
> want to compete ;)
>

One of ideas, i like in VW Xtreams is an ease of creating transforming streams:

        "hex encoding: #[0 1 2 ... 255] -> '000102...FF' "
        bytes := ByteArray withAll: (0 to: 255).
        digits := '0123456789ABCDEF'.
        byte2hex := [ :in :out || byte |
                byte := in get.
                out put: (digits at: (byte bitShift: -4) + 1).
                out put: (digits at: (byte bitAnd: 15) + 1) ].
        (bytes reading transforming: byte2hex)
                contentsSpecies: String;
                rest


here
bytes reading, answers a reader xtream
then by sending #transforming: aBlock
you wrap this stream with transforming stream, which using a block for
transformations.
note, that block takes in and out arguments, which are streams
instead of taking a single argument, like a next element read from
source stream.
In this way you can control transformation in any way you like:
- read N elements from source and produce M elements as output.

This is very powerful. Simplest example , which comes in mind is our
beloved UTF8 reader
- it may read 1, 2, 3 or 4 bytes from source to produce 1 character at output.

What i like in it, that you don't need to create a separate class for
each kind of transformation,
since you can simply construct it on the fly using blocks, like:

Xtream>>decodeUTF8
  ^ self transforming: [:in :out |
   byte :=  in get.
   .... (utf 8 decoding logic )
   out put: result ]


> Nicolas
>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list