2010/10/8 Igor Stasenko <[email protected]>: > On 8 October 2010 23:13, Nicolas Cellier > <[email protected]> wrote: >> 2010/10/8 Igor Stasenko <[email protected]>: >>> 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 ] >
Yes, this is a very nice generalization indeed. The Squeak_XTream-Parallel package has a totally screwed implementation of it. It's less simple than it sounds ;) Nicolas > >> Nicolas >> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
