[squeak-dev] Character>to: was changed and breaks ObjectsTool

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Jul 19 11:05:34 UTC 2013


First, let's forget about OrderedCollection, that's just Levente's post
that misguided me.
The old behaviour was to return an Array, so you couldn't add: either.

In your example, you explicitely asked for an Array, then you select: an
Array, that seems fair.
I see no reason why we would change that to a String.

That's different from ($a to: $z) case where we did not explicitely
requested an Array.
Some code does indeed implicitely expect an Array, and I broke it, because
- as you said, it's hard to analyze source (many senders)
- and as we all know, we lack a few tests here and there (well, it's a
joke, we lack more than we have, but that's a debt from the past that we
slowly refund)

But let's return to these expectations.
An Array of Character has not much value per se. I mean that's exactly what
a String is, an Array of Character...
Except that the String is much much reacher with a bunch of specialized
methods (because we know it contains Character).
So to me, the most logical thing to do remains to answer a String.
I'm not the only one to share this logic, look what Character class methods
do:

{Character alphabet. Character separators. Character allByteCharacters}
collect: #class as: Set

The only difference with String is when you collect: something else than
Character, and that's what you bumped into.
But as Levente said, we have very convenient collect:as: for this special
case.
So, I agree that I changed the contract and broke some code, but that's an
easy to fix and probably rare problem.
To me the balance benefits/costs is fair.

This knowledge should go into some realease notes at least, in order to
ease upgrades.
But we are not yet at this level of maturity...

Cheers



2013/7/18 tim Rowledge <tim at rowledge.org>

>
> On 18-07-2013, at 3:47 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> > I did the change and the rationale is that the most logical Collection
> recipient for Character is String, what else?
>
> I'm not at all sure I agree there; yes, as mentioned before a String is a
> collection of Characters in some sense - but one should also consider an
> Interval as an Array that is specified by shorthand that relies on a known
> ordering. If we wrote
> (Array with: $a with: $b with: $c) select:[:c| c =$b]
> should we get #($b) or 'b' ? I think #($b) is correct.
>
> > OrderedCollection is totally arbitrary with this respect.
> > OK, you cannot add: to a String. But can you add: to (1 to: 10)? No you
> can't.
>
> That's why #species is there - to provide a suitable recipient for the
> results of enumerations when running over such objects.
>
> > So, put together, the Rationale is simply a principle of least
> astonishment.
>
> The practical problem is that even though I'm sure you looked to see what
> problems the change might cause  - because you're nice (how often do I get
> to make a fun pun on someone's name?) - you can't easily be sure that you
> can even see all the places where it might be troublesome. It broke a
> relatively basic tool that I stumbled upon because it is mentioned in a
> tutorial. How can we feel sure it doesn't affect other bits of code? I
> don't think it's terribly practical to search out every use of #to: (or
> other Interval creation methods) and then dig around to find out how it got
> used subsequently, it's simply too common an idiom. Within one's own
> special code it can still be tricky if the project has grown large (ask me
> about grokking Scratch…) but in the general case? Forget it, unless
> somebody has a project to really, truly automate it. And in all the cases
> where we didn't catch the problem, somebody is going to be unpleasantly
> astonished.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> No, I don't explode cats. It's way too difficult to coax them into the
> microwave - http://tinyurl.com/yp3hgr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130719/2bec1e7b/attachment.htm


More information about the Squeak-dev mailing list