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
