[Pharo-project] XTream was Re: Re: Ocean (was Re: Less plugins, more Smalltalk code!)
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
> 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
> 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)
bytes reading, answers a reader xtream
then by sending #transforming: aBlock
you wrap this stream with transforming stream, which using a block for
note, that block takes in and out arguments, which are streams
instead of taking a single argument, like a next element read from
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:
^ self transforming: [:in :out |
byte := in get.
.... (utf 8 decoding logic )
out put: result ]
>> Best regards,
>> Igor Stasenko AKA sig.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev