Collection with memory?
Locked
12
12
 
|
>>>> 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. 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 |
Re: Collection with memory?
|
|
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 <[hidden email]> 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 > > > |
|
|
In reply to this post by stepharo
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-IQbservable-The-Dual-of-IQueryable I don't know if this is enough to improve your live but I'm sure at least you will enjoy ;) -- Regards, Alain |
|
|
In reply to this post by Sven Van Caekenberghe-2
> 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. 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 <[hidden email]> 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 >> >> >> > > |
Re: Collection with memory?
|
|
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 <[hidden email]> 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 <[hidden email]> 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. > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |