2010/10/8 Igor Stasenko <[email protected]>: > Nicolas, > the design of your version lacks composability. > Also, i seriously think that read and write streams should not be > married under same class. > This could be a paradigm shift for many people, but not for me, since > i dealt with real-time > network communications in the past and can say that network > communication based on bidirectional data flow > really sucks, because it doesn't scale.. and don't works for more than > 2 peers :) >
I don't see what is not composable. Squeak Xtream is made exclusively of Xtream wrappers, except some terminal CollectionReadXtream and future IOHandleReadXtream (not yet existing see below). Track how the source/destination ivar are defined/used : most exclusively of other Xtreams. Also check the messages ~> and <~ for composition. I started using Stream wrappers in the 90s for my own applications, that's not a new idea. > By its nature, data flow is unidirectional. Trying to unify things and > present it as a bidirectional > leads to bad code, bad usage patterns (see RemoteString) and > endless discussions around 'do we need a multiple inheritance or not'. > Agree. I have mostly separated ReadXtream and WriteXtream with one exception, the so called BufferedReadWriteXtream. This class was a quick hack and is not satisfying me. In Squeak, there is one major user of ReadWriteStream: the change log, so I needed this quick hack. We can for sure decompose it in two streams, one for read, one for write, code will be a lot cleaner. But beware, the two streams will have to share a common state, and implementation is not straightforward. If you look at VW implementation, you will see this kind of object is a (shared) Buffer and the implementation is quite involved... But if you want to help with this one, you're welcome. > If i want to read from stream, i can do it like following: > > file := 'foo.txt' asFile. > > reader := file readXStream. > reader next > > if i want to write something, i do > > writer := file writeXStream. > writer nextPut: $x. > > and if i need to read & write both, then i probably should tell writer > and reader > to share same state, like file handle, cache, buffers etc, but not to > be the same object. > so, if i need to write, i should use writer, and if i need to read - i > should use reader.. > > Concerning composability, this is a cornerstone of VW XTreams implementation. > And after watching their presentation at ESUG, i can say that your > implementation completely miss the point (sorry). > Seeing how simple i can build complex parser(s) by composing multiple > low-level parsers > in PetitParser, nobody can convince me, that its a bad idea for streams. > > Why i can't simply do: > > reader := 'aaa.txt' asFile readXStream. > utf8Reader := UTF8Reader on: reader. > ? > 1) asFile does not exist yet because I thought it would be much better to conect to FileSystem http://www.wiresong.ca/downloads/Filesystem-1.0.0.sar rather than doing yet another one... 2) in the meantime, use an old StandardFileStream (yes I know, not sexy) 3) compose with message <~ for write and ~> for read By now your example shall be translated as (StandardFileStream readOnlyFileNamed: 'aaa.txt') readXtream buffered ~> UTF8Decoder. Buffering could be automated at FSReadXtream creation. The utf8 decoder should also be buffered, but it's just a matter of creating a nice shortCut for composition, maybe simply 'aaa.txt' asFile readXtream gunzip utf8. Instead of #on:, I implemented #onStream: for readXtream wrappers and #toStream: for writeXtream wrappers. I concede current implementation is weak because those two messages are duplicated... But it's just a matter of gathering the transformers under a generic subclass as you proposed in Xtream-Wrappers Hope it helps, or maybe there are really neat things I missed ? VW Xtream is really a master piece, reach features, certainly many hours of development. Squeak Xtream is a few hours proof of concept. I invite you and every one interested to complete the work. Beside, VW Xtream is now MIT, so it's easy to pick any code and unify if there's a will in this community. Nicolas > > On 8 October 2010 00:51, Nicolas Cellier > <[email protected]> wrote: >> 2010/10/7 Stéphane Ducasse <[email protected]>: >>> pay attention that there are two xtreams package frameworks from what I >>> understand >>> >>> one presented at esug and one developed by nicolas >>> >>> Stef >>> >> >> Now, I wonder if I should not rename it SqueaXtream or something - >> apologize for not being Pharo-tically correct ;) >> >> Nicolas >> >>> On Oct 7, 2010, at 4:58 PM, Sven Van Caekenberghe wrote: >>> >>>> >>>> On 06 Oct 2010, at 08:48, Nicolas Cellier wrote: >>>> >>>>> See also hijacked http://www.squeaksource.com/XTream.html borrowing >>>>> some of the ideas, but somehow less extreme. >>>>> Most packages should now load in Pharo. >>>> >>>> Hi Nicolas, >>>> >>>> I have been looking at the ESUG 2010 slides & google code project pages of >>>> xstreams and I must say that I like this very much. >>>> >>>> Your code on SS does indeed load in Pharo 1.1. 8 tests fail out of 37 with >>>> errors that I think are probably fixable. I am browsing it now. >>>> >>>> Now my question is, first, do you have some write up somewhere explaining >>>> what you did and why, and second, what is the current state of your >>>> project and what are your future plans/goals ? >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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
