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 at 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 at 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
> >   !
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140829/9e546b06/attachment.htm