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

Chris Muller asqueaker at gmail.com
Sun Aug 11 20:44:05 UTC 2013


> I was fairly sold on your arguments but that these two are no longer
> commutative has caused some doubt to start creeping in.

Ok, maybe not that their not commutative, because there are other
cases where the class of the receiver determines the class of the
result.

But we should watch out for code that is wanting to defined limited
Character sets using , (comma) concatenation..



>
> With our new friendly String concatenation Andreas introduced in 2009
> for safer error-handling, I can see there might be a plurality of
> cases like the above.
>
> On Fri, Jul 19, 2013 at 6:05 AM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 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
>>>
>>>
>>
>>
>>
>>


More information about the Squeak-dev mailing list