Hi I need a collection that does the following: col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13 Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper. Stef
may be a first step would be to have findFirst: aBlock startingAt: based on findFirst: findFirst: aBlock "Return the index of my first element for which aBlock evaluates as true." | index | index := 0. [(index := index + 1) <= self size] whileTrue: [(aBlock value: (self at: index)) ifTrue: [^index]]. ^ 0
Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
Le 22/03/2015 18:57, stepharo a écrit :
may be a first step would be to have findFirst: aBlock startingAt: based on findFirst:
findFirst: aBlock "Return the index of my first element for which aBlock evaluates as true."
| index | index := 0. [(index := index + 1) <= self size] whileTrue: [(aBlock value: (self at: index)) ifTrue: [^index]]. ^ 0
Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
May be this "memory" could be implemented in another object (and/or Traits?) , allowing several threads to traverse the collection, and add extensibility to the collection framework. The general idea, inspired from dotnet+smalltalk (I don't know if this fit well with smalltalk patterns, may be total junk and not doable ? -btw it's just a proposition) Collection>> asQueryable "=> a Queryable Object that would implement first, next, based on a predicate." ^Queryable on: self readStream. Queryable class >> on: aStream ^self new on: aStream Queryable>> where: aPredicateBlock self predicate: aPredicateBlock Queryable>> first self stream reset . ^self next. Queryable>>next [self stream atEnd not and: [ (self predicate value: (current := self stream next)))] whileFalse. ^ self stream atEnd ifTrue: [nil] ifFalse: [self current]. (...) col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asQueryable where: [:each | each first = $a]. col first. -> 'a12' col next. -> 'a13' Those dotnet linq patterns are cool, on a dynamic langage like smalltalk with tools like GTInspector + roassal and Moose, wouldn't it be ultra cool ? :) -- Regards, Alain
This is like the Iterator Design pattern and this is interesting. Why don't you give a try to see how it grows? Thanks Alain
May be this "memory" could be implemented in another object (and/or Traits?) , allowing several threads to traverse the collection, and add extensibility to the collection framework.
The general idea, inspired from dotnet+smalltalk (I don't know if this fit well with smalltalk patterns, may be total junk and not doable ? -btw it's just a proposition)
Collection>> asQueryable "=> a Queryable Object that would implement first, next, based on a predicate." ^Queryable on: self readStream.
Queryable class >> on: aStream ^self new on: aStream
Queryable>> where: aPredicateBlock self predicate: aPredicateBlock
Queryable>> first self stream reset . ^self next. Queryable>>next [self stream atEnd not and: [ (self predicate value: (current := self stream next)))] whileFalse. ^ self stream atEnd ifTrue: [nil] ifFalse: [self current]. (...)
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asQueryable where: [:each | each first = $a]. col first. -> 'a12' col next. -> 'a13'
Those dotnet linq patterns are cool, on a dynamic langage like smalltalk with tools like GTInspector + roassal and Moose, wouldn't it be ultra cool ? :)
Le 22/03/2015 22:39, stepharo a écrit :
This is like the Iterator Design pattern and this is interesting. Yes, usually in dotnet IQueryable is implemented by (or on top of) a IEnumerable. It is one of the key elements of Linq that makes Linq very user friendly for developers Why don't you give a try to see how it grows? I did a small try . it works, and there was not too much errors in my suggestion . sometimes I surprise myself ... ;-) I think it could be cool not only for collections, but with Glorp for example (translate predicates to sql, some kind of "Linq for smalltalk"). I think I'll dig a bit in that direction May be time for some explorations with Glorp.
-- Regards, Alain
Le 22/3/15 23:10, Alain Rastoul a écrit :
Le 22/03/2015 22:39, stepharo a écrit :
This is like the Iterator Design pattern and this is interesting. Yes, usually in dotnet IQueryable is implemented by (or on top of) a IEnumerable. It is one of the key elements of Linq that makes Linq very user friendly for developers Why don't you give a try to see how it grows? I did a small try . it works, and there was not too much errors in my suggestion . sometimes I surprise myself ... ;-) I think it could be cool not only for collections, but with Glorp for example (translate predicates to sql, some kind of "Linq for smalltalk"). I think I'll dig a bit in that direction May be time for some explorations with Glorp. Excellent! Improve our lives :)
Hi Stef Thinking to that today, I remembered myself two excellent links on this subject. Googling a bit to retrieve the links gave me tons of interesting stuff (reactive, linq etc), but those ones are "classicals" . Erik Meijer on duality of Enumerable and Observer http://csl.stanford.edu/~christos/pldi2010.fit/meijer.duality.pdf and Bart De Smet about Enumerables, Observables, Pull vs Push model, Cloud http://channel9.msdn.com/Shows/Going+Deep/Bart-De-Smet-Observations-on-IQbse... I don't know if this is enough to improve your live but I'm sure at least you will enjoy ;) -- Regards, Alain
Hi It is another perfect task for XStreams: r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13 2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>:
Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Beautiful ! Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
It is, indeed. Doru On Sun, Mar 22, 2015 at 10:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Beautiful !
Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
-- www.tudorgirba.com "Every thing has its own flow"
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13 Beautiful !
Yes but with r next. r next I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50. :)
Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
On 22 Mar 2015, at 22:40, stepharo <stepharo@free.fr> wrote:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13 Beautiful !
Yes but with r next. r next
The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point.
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50. :)
Well, it does/did load OK in Pharo 3 and probably will in 4 too. https://ci.inria.fr/pharo-contribution/job/Xtreams/
Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
Le 22/3/15 23:01, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 22:40, stepharo <stepharo@free.fr> wrote:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13 Beautiful ! Yes but with r next. r next The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point. No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4
superb inconsistencet
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50. :) Well, it does/did load OK in Pharo 3 and probably will in 4 too.
Yes loading is just a part of the story :) We should remove the old ones. And we should revise the API because I **hate ++, -=, +=
Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
On 23 Mar 2015, at 07:57, stepharo <stepharo@free.fr> wrote:
Le 22/3/15 23:01, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 22:40, stepharo <stepharo@free.fr> wrote:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13 Beautiful ! Yes but with r next. r next The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point. No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4
IIRC, one difference between #get and #next is that get cannot return nil and will throw an Incomplete exception when EOF next can return nil and might throws an Exception Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong.
superb inconsistencet
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50. :) Well, it does/did load OK in Pharo 3 and probably will in 4 too.
Yes loading is just a part of the story :) We should remove the old ones.
And we should revise the API because I **hate ++, -=, +=
Yeah, but is not because it looks a bit like C++ that it is no longer Smalltalk, these are still normal messages. But yes, some API discussions are possible.
Thx Denis.
2015-03-22 20:47 GMT+03:00 stepharo <stepharo@free.fr>: Hi
I need a collection that does the following:
col := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') asMyNewCollection. col findFirst: [:each | each first = $a] > a12 col findFirst: [:each | each first = $a] > a13
Do you know a collection that would work? So I have the impression that such behavoir could be defined with a kind of methods wrapper.
Stef
No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4 IIRC, one difference between #get and #next is that
get cannot return nil and will throw an Incomplete exception when EOF next can return nil and might throws an Exception
Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong.
superb inconsistencet
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50. :) Well, it does/did load OK in Pharo 3 and probably will in 4 too.
https://ci.inria.fr/pharo-contribution/job/Xtreams/ Yes loading is just a part of the story :) We should remove the old ones.
And we should revise the API because I **hate ++, -=, += Yeah, but is not because it looks a bit like C++ that it is no longer Smalltalk, these are still normal messages.
But yes, some API discussions are possible.
Yes but with r next. r next The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point. No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4 IIRC, one difference between #get and #next is that
get cannot return nil and will throw an Incomplete exception when EOF next can return nil and might throws an Exception
Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong. Indeed now this is still not a nice API. So what would be a nice name for get
I do not get it. I'm probably too tired get so it is named get and not next. get cannot return nil and will throw an Incomplete exception when EOF but next: that could be confused with next can return nil and might throws an Exception (because it should follow next) :) No stupid stef. next: is from xtreams so it should follow get get cannot return nil and will throw an Incomplete exception when EOF Ahhhhhhhh this is probably clear. So could we be consistent nextItem nextItems: putItem: Now since in anyways people will have to revisit they wrapping of next calls which should probably wraped into and Exception. I do not see the problem. It is because there is a wrapper that would turn an Xstream stream into a old API (then again I do not understand because since the wrapper is another class it can have a next method that delegates to the correct wrapped xstream which may have or not the same api. So what is the point? I mean once xtream will replace the old one it will be for about 10 years so I'm sorry but we should get the api right (and yes I know that ++ -= are correct smalltalk still they SUCK). Stef
Stef, Like Denis said, there is no #next: in Xtreams, AFIACT. There are XTReadStream>>#get "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised." and XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised." Like I said, these selector names were chosen to prevent confusion, on purpose. I think that is good. I also think that a lot of though went into the design. #++ could be aliased to #seekForward: and #-- to #seekBackward: I guess. I also do not really like the look of them. BTW, I think that the compatibility layer/wrapper is not good (I would be very surprised if it could hide all the semantic differences). What is the point to switch to a new stream API if you hide it ? Also, the current stream API is 'too wide', there are too many methods, too much is expected from streams. To change that, the users must be changed. Sven
On 23 Mar 2015, at 22:06, stepharo <stepharo@free.fr> wrote:
Yes but with r next. r next The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point. No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4 IIRC, one difference between #get and #next is that
get cannot return nil and will throw an Incomplete exception when EOF next can return nil and might throws an Exception
Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong. Indeed now this is still not a nice API. So what would be a nice name for get
I do not get it. I'm probably too tired
get so it is named get and not next. get cannot return nil and will throw an Incomplete exception when EOF but next: that could be confused with next can return nil and might throws an Exception (because it should follow next) :) No stupid stef. next: is from xtreams so it should follow get get cannot return nil and will throw an Incomplete exception when EOF Ahhhhhhhh this is probably clear.
So could we be consistent
nextItem nextItems: putItem:
Now since in anyways people will have to revisit they wrapping of next calls which should probably wraped into and Exception. I do not see the problem. It is because there is a wrapper that would turn an Xstream stream into a old API (then again I do not understand because since the wrapper is another class it can have a next method that delegates to the correct wrapped xstream which may have or not the same api. So what is the point?
I mean once xtream will replace the old one it will be for about 10 years so I'm sorry but we should get the api right (and yes I know that ++ -= are correct smalltalk still they SUCK).
Stef
Stef,
Like Denis said, there is no #next: in Xtreams, AFIACT.
Yes but this is the same we should get read and read: and not get and read: This is my point.
There are
XTReadStream>>#get "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised."
and
XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised."
Like I said, these selector names were chosen to prevent confusion, on purpose. I think that is good. I also think that a lot of though went into the design.
I personally think that get and read: are bad and irregular. XTReadStream>>#read "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised." XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised." funny how the comments are good. No need to change them. This is a sign.
#++ could be aliased to #seekForward: and #-- to #seekBackward: I guess. I also do not really like the look of them.
I will not aliased them. Just deprecate them :) I do not want to have to always scratch my head to understand the code seekForward and seekBackward is much much nicer.
BTW, I think that the compatibility layer/wrapper is not good (I would be very surprised if it could hide all the semantic differences). What is the point to switch to a new stream API if you hide it ?
Incremental migration.
Also, the current stream API is 'too wide', there are too many methods, too much is expected from streams. To change that, the users must be changed.
Yes we will do that.
Sven
On 23 Mar 2015, at 22:06, stepharo <stepharo@free.fr> wrote:
Yes but with r next. r next The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point. No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4 IIRC, one difference between #get and #next is that
get cannot return nil and will throw an Incomplete exception when EOF next can return nil and might throws an Exception
Changing the meaning of an existing selector will cause many problems and discussions. People will think they do not have to change anything and they will be wrong. Indeed now this is still not a nice API. So what would be a nice name for get
I do not get it. I'm probably too tired
get so it is named get and not next. get cannot return nil and will throw an Incomplete exception when EOF but next: that could be confused with next can return nil and might throws an Exception (because it should follow next) :) No stupid stef. next: is from xtreams so it should follow get get cannot return nil and will throw an Incomplete exception when EOF Ahhhhhhhh this is probably clear.
So could we be consistent
nextItem nextItems: putItem:
Now since in anyways people will have to revisit they wrapping of next calls which should probably wraped into and Exception. I do not see the problem. It is because there is a wrapper that would turn an Xstream stream into a old API (then again I do not understand because since the wrapper is another class it can have a next method that delegates to the correct wrapped xstream which may have or not the same api. So what is the point?
I mean once xtream will replace the old one it will be for about 10 years so I'm sorry but we should get the api right (and yes I know that ++ -= are correct smalltalk still they SUCK).
Stef
OK, I get your point now, #read and #read: are a better combination than #get and #read: About #++ and friends, yes I think they are so uncommon that they do not warrant a special selector, what is the point ?
On 25 Mar 2015, at 09:12, stepharo <stepharo@free.fr> wrote:
Stef,
Like Denis said, there is no #next: in Xtreams, AFIACT.
Yes but this is the same we should get read and read: and not get and read: This is my point.
There are
XTReadStream>>#get "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised."
and
XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised."
Like I said, these selector names were chosen to prevent confusion, on purpose. I think that is good. I also think that a lot of though went into the design.
I personally think that get and read: are bad and irregular.
XTReadStream>>#read "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised."
XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised."
funny how the comments are good. No need to change them. This is a sign.
Le 25/3/15 09:32, Sven Van Caekenberghe a écrit :
OK, I get your point now, #read and #read: are a better combination than #get and #read:
About #++ and friends, yes I think they are so uncommon that they do not warrant a special selector, what is the point ?
do not let creep in bad ideas! I can tell you from a dyslexic point of view i++ ++i and all cryptic things that makes a programmer feels like a real men is not fun. Let us use them carefully not as "look mum I can do it" Stef
On 25 Mar 2015, at 09:12, stepharo <stepharo@free.fr> wrote:
Stef,
Like Denis said, there is no #next: in Xtreams, AFIACT. Yes but this is the same we should get read and read: and not get and read: This is my point. There are
XTReadStream>>#get "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised."
and
XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised."
Like I said, these selector names were chosen to prevent confusion, on purpose. I think that is good. I also think that a lot of though went into the design. I personally think that get and read: are bad and irregular.
XTReadStream>>#read "Read an object from self. If there aren't any elements left in the stream, the Incomplete exception is raised."
XTReadStream>>#read: anInteger "Read anInteger's worth of elements from self and return them in a collection. If full anInteger number of elements cannot be read from the source, the Incomplete exception is raised."
funny how the comments are good. No need to change them. This is a sign.
2015-03-23 9:57 GMT+03:00 stepharo <stepharo@free.fr>:
Le 22/3/15 23:01, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 22:40, stepharo <stepharo@free.fr> wrote:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com>
wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Beautiful !
Yes but with r next. r next
The choice for different selector names was intentional, by design. To avoid confusion, because #next and #get are not 100% identical (semantically). This is an important point.
No I asked martin personally. This is the real reason. There were also experimenting to offer an API closer to other language. So that we have r get. r next: 4
But in original docs from https://code.google.com/p/xtreams there are only #get and #read: messages.
2015-03-23 0:40 GMT+03:00 stepharo <stepharo@free.fr>:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Beautiful !
Yes but with r next. r next
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50.
I think it is important to have XStreams in pharo by default. Because current streams (from Smalltalk 80) are too powerfull. And when XStreams not in image or can't be loaded easilly people can prefer to use existed streams solution. I was such man when I was need quickly solve some parsing and analizing data task but I can't load XStreams. And I was solve my task with classic streams. It was simple solution. But with XStreams it will be much compact and intuitive implementation.
The problem is that - we do not want to open alone another subproject - we would like to remove the old stream (make them loadable) - we should not get the system with two stream libraries. Stef Le 23/3/15 10:06, Denis Kudriashov a écrit :
2015-03-23 0:40 GMT+03:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Le 22/3/15 22:05, Sven Van Caekenberghe a écrit :
On 22 Mar 2015, at 21:44, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Beautiful !
Yes but with r next. r next
I was reading the XTreams API recently but this is forbidden for me to open another project before finishing what I started. Now if somebody else would like to help pushing Xtreams in Pharo 50.
I think it is important to have XStreams in pharo by default. Because current streams (from Smalltalk 80) are too powerfull. And when XStreams not in image or can't be loaded easilly people can prefer to use existed streams solution. I was such man when I was need quickly solve some parsing and analizing data task but I can't load XStreams. And I was solve my task with classic streams. It was simple solution. But with XStreams it will be much compact and intuitive implementation.
Le 22/03/2015 21:44, Denis Kudriashov a écrit :
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Looks interesting :) You have a link for this package in Pharo (or squeak) ? I found only java package, or mails and slides talking of it in smalltalk TIA -- Regards, Alain
https://code.google.com/p/xtreams/ Le 22/3/15 22:27, Alain Rastoul a écrit :
Le 22/03/2015 21:44, Denis Kudriashov a écrit :
Hi
It is another perfect task for XStreams:
r := #('a12' 'b12' 'a13' 'a14' 'c23' 'a16') reading selecting: [:each | each first = $a]. r get > a12 r get > a13
Looks interesting :) You have a link for this package in Pharo (or squeak) ? I found only java package, or mails and slides talking of it in smalltalk TIA
Le 22/03/2015 22:42, stepharo a écrit :
https://code.google.com/p/xtreams/ Thank you, I just found it too by watching the Martin Kobetic video on youtube. Very interesting
-- Regards, Alain
participants (5)
-
Alain Rastoul -
Denis Kudriashov -
stepharo -
Sven Van Caekenberghe -
Tudor Girba