Streams. Status and where to go?
Locked
Streams. Status and where to go?
 
|
Hello,
i am cross-posting, since i think it is good for all of us to agree on some common points. 1. Streams needs to be rewritten. 2. What do you think is good replacement for current Streams? personally, i currently need a fast and concise UTF8 reader. The UTF8TextConverter is closest thing what i would take, but i don't understand, why it implemented as a non-stream? The #nextFromStream: and #nextPut:toStream: crying out of loud to be just #next and #nextPut: Another thing which makes me sad is this line: nextFromStream: aStream | character1 value1 character2 value2 unicode character3 value3 character4 value4 | aStream isBinary ifTrue: [^ aStream basicNext]. <<<<<<< All external streams is initially binary , but UTF8TextConverter wants to play with characters, instead of octets.. But hey... UTF8 encoding is exactly about encoding unicode characters into binary form.. I'm not even mentioning that operating with bytes (smallints) is times more efficient than operating with characters (objects), because first thing it does: character1 := aStream basicNext. " a #basicNext, obviously, reads a byte from somewhere and then converts it to instance of Character. 'Bonus' overhead here. " character1 isNil ifTrue: [^ nil]. value1 := character1 asciiValue. " and... what a surprise, we converting a character back to integer value.. What a waste! " value1 <= 127 ifTrue: [ I really hope, that eventually we could have a good implementation, where horse runs ahead of cart, not cart ahead of horse :) Meanwhile i think i have no choice but make yet-another implementation of utf8 reader in my own package, instead of using existing one. -- Best regards, Igor Stasenko AKA sig. |
Re: Streams. Status and where to go?
|
|
I think someone in the know should have a good look at Craig's Flow implementation.
This has been available for years, yet people seem to avoid looking seriously at it. I believe Craig had it working on 3.9 at one point not so long ago and therefore it should work on 3.10 as well. Unless perhaps there is some compelling issue I do not know about or understand that says it should not be used. I think at the time it became available, there was no convenient way to have both Flow and the old implementation installed at the same time, that's mainly why it did not get accepted. Perhaps someone else can add to this. Ken G. Brown At 8:11 PM +0200 2/25/10, Igor Stasenko apparently wrote: >Hello, > >i am cross-posting, since i think it is good for all of us to agree on >some common points. > >1. Streams needs to be rewritten. >2. What do you think is good replacement for current Streams? > >personally, i currently need a fast and concise UTF8 reader. >The UTF8TextConverter is closest thing what i would take, but i don't >understand, why >it implemented as a non-stream? > >The #nextFromStream: >and #nextPut:toStream: >crying out of loud to be just >#next >and >#nextPut: > >Another thing which makes me sad is this line: > >nextFromStream: aStream > > | character1 value1 character2 value2 unicode character3 value3 >character4 value4 | > aStream isBinary ifTrue: [^ aStream basicNext]. <<<<<<< > > >All external streams is initially binary , but UTF8TextConverter wants >to play with characters, instead of octets.. >But hey... UTF8 encoding is exactly about encoding unicode characters >into binary form.. >I'm not even mentioning that operating with bytes (smallints) is times >more efficient than operating with characters (objects), because first >thing it does: > > character1 := aStream basicNext. " a #basicNext, obviously, reads a >byte from somewhere and then converts it to instance of Character. >'Bonus' overhead here. " > character1 isNil ifTrue: [^ nil]. > value1 := character1 asciiValue. " and... what a surprise, we >converting a character back to integer value.. What a waste! " > value1 <= 127 ifTrue: [ > >I really hope, that eventually we could have a good implementation, >where horse runs ahead of cart, not cart ahead of horse :) >Meanwhile i think i have no choice but make yet-another implementation >of utf8 reader in my own package, instead of using existing one. > >-- >Best regards, >Igor Stasenko AKA sig. |
Re: Streams. Status and where to go?
|
|
In reply to this post by Igor Stasenko
Check out Xtreams. It's now released under MIT; so all it takes is
someone to port it. It looks quite interesting. http://code.google.com/p/xtreams/ http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Xtreams_under_the_MIT_License&entry=3444118235 Cheers, - Andreas Igor Stasenko wrote: > Hello, > > i am cross-posting, since i think it is good for all of us to agree on > some common points. > > 1. Streams needs to be rewritten. > 2. What do you think is good replacement for current Streams? > > personally, i currently need a fast and concise UTF8 reader. > The UTF8TextConverter is closest thing what i would take, but i don't > understand, why > it implemented as a non-stream? > > The #nextFromStream: > and #nextPut:toStream: > crying out of loud to be just > #next > and > #nextPut: > > Another thing which makes me sad is this line: > > nextFromStream: aStream > > | character1 value1 character2 value2 unicode character3 value3 > character4 value4 | > aStream isBinary ifTrue: [^ aStream basicNext]. <<<<<<< > > > All external streams is initially binary , but UTF8TextConverter wants > to play with characters, instead of octets.. > But hey... UTF8 encoding is exactly about encoding unicode characters > into binary form.. > I'm not even mentioning that operating with bytes (smallints) is times > more efficient than operating with characters (objects), because first > thing it does: > > character1 := aStream basicNext. " a #basicNext, obviously, reads a > byte from somewhere and then converts it to instance of Character. > 'Bonus' overhead here. " > character1 isNil ifTrue: [^ nil]. > value1 := character1 asciiValue. " and... what a surprise, we > converting a character back to integer value.. What a waste! " > value1 <= 127 ifTrue: [ > > I really hope, that eventually we could have a good implementation, > where horse runs ahead of cart, not cart ahead of horse :) > Meanwhile i think i have no choice but make yet-another implementation > of utf8 reader in my own package, instead of using existing one. > |
Re: Streams. Status and where to go?
|
|
In reply to this post by Ken G. Brown
On 2010-02-25, at 10:33 AM, Ken G. Brown wrote: > I think someone in the know should have a good look at Craig's Flow implementation. > This has been available for years, yet people seem to avoid looking seriously at it. > I believe Craig had it working on 3.9 at one point not so long ago and therefore it should work on 3.10 as well. > > Unless perhaps there is some compelling issue I do not know about or understand that says it should not be used. > > I think at the time it became available, there was no convenient way to have both Flow and the old implementation installed at the same time, that's mainly why it did not get accepted. I took a look at Flow recently, with an eye toward pillaging it for the stream implementations. I decided against it, though, because Flow streams are still organized as a hierarchy of stream classes. It's maybe a saner hierarchy, maybe the code is nicer, but I don't think it solves the fundamental problem, which is that inheritance is not a very powerful design tool. Composition is much more powerful, and I think composable streams are the only way to achieve the functionality and flexibility that we need. So yeah, Flow is better than what we've got, but we should aim higher. Colin |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |