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 <steph...@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 > > >
