On 8 October 2010 23:13, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2010/10/8 Igor Stasenko <siguctua@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.