Maybe.

I think this came about from the MutliByteFileStream work, where there are a lot of #basic.. calls. The idea there is to bypass the MultiByte work, and use the more basic version of the calls. In that class it translates into a super call of the normal call (so, #basicUpTo: calls super upTo:).

I suspect the phrase #basicUpTo: is in refers to the basic for of upTo: and not the complex form of upTo:.

In either case, this fix was to just fix a lurking bug, not addressing the naming of the calls already there.

-cbc

On Fri, Aug 29, 2014 at 8:37 AM, Chris Muller asqueaker@gmail.com wrote:

Just from a API-structure POV, shouldn't the user-API's call the lower-level "basic" API's instead of vice-versa?

IOW, "basic..." methods are meant for low-level implementations while the non-basic are meant for user-access. Low-level implementations calling the higher-level user methods smells..

On Fri, Aug 29, 2014 at 9:39 AM, commits@source.squeak.org wrote:

...

A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-cbc.581.mcz

==================== Summary ====================

Name: Collections-cbc.581 Author: cbc Time: 29 August 2014, 7:39:32.599 am UUID: a38b6f89-e4f2-7b4b-99d3-eeafa9c35445 Ancestors: Collections-nice.580

Fix #basicUpTo: to call #upTo: instead of #next:

=============== Diff against Collections-nice.580 ===============

Item was changed: ----- Method: PositionableStream>>basicUpTo: (in category 'accessing -

multibyte support') -----

...

basicUpTo: anObject

•   ^self upTo: anObject
  

•   ^self next: anObject
  

  !