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