<div dir="ltr"><div><div><div>First, let's forget about OrderedCollection, that's just Levente's post that misguided me.<br></div><div>The old behaviour was to return an Array, so you couldn't add: either.<br>
</div><div><br>In your example, you explicitely asked for an Array, then you select: an Array, that seems fair.<br>I see no reason why we would change that to a String.<br><br></div><div>That's different from ($a to: $z) case where we did not explicitely requested an Array.<br>
</div><div>Some code does indeed implicitely expect an Array, and I broke it, because<br>- as you said, it's hard to analyze source (many senders)<br></div><div>- 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)<br>
</div><div><br></div><div>But let's return to these expectations.<br></div>An Array of Character has not much value per se. I mean that's exactly what a String is, an Array of Character...<br>Except that the String is much much reacher with a bunch of specialized methods (because we know it contains Character).<br>
</div><div>So to me, the most logical thing to do remains to answer a String.<br></div><div>I'm not the only one to share this logic, look what Character class methods do:<br><br>{Character alphabet. Character separators. Character allByteCharacters} collect: #class as: Set<br>
</div><div><br></div>The only difference with String is when you collect: something else than Character, and that's what you bumped into.<br></div><div>But as Levente said, we have very convenient collect:as: for this special case.<br>
</div><div>So, I agree that I changed the contract and broke some code, but that's an easy to fix and probably rare problem.<br></div><div>To me the balance benefits/costs is fair.<br></div><div><br></div><div>This knowledge should go into some realease notes at least, in order to ease upgrades.<br>
But we are not yet at this level of maturity...<br><br></div><div>Cheers<br></div><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/18 tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 18-07-2013, at 3:47 AM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> I did the change and the rationale is that the most logical Collection recipient for Character is String, what else?<br>
<br>
</div>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<br>
(Array with: $a with: $b with: $c) select:[:c| c =$b]<br>
should we get #($b) or 'b' ? I think #($b) is correct.<br>
<div class="im"><br>
> OrderedCollection is totally arbitrary with this respect.<br>
> OK, you cannot add: to a String. But can you add: to (1 to: 10)? No you can't.<br>
<br>
</div>That's why #species is there - to provide a suitable recipient for the results of enumerations when running over such objects.<br>
<div class="im"><br>
> So, put together, the Rationale is simply a principle of least astonishment.<br>
<br>
</div>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.<br>
<div class="im"><br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
</div>No, I don't explode cats. It's way too difficult to coax them into the microwave - <a href="http://tinyurl.com/yp3hgr" target="_blank">http://tinyurl.com/yp3hgr</a><br>
<br>
<br>
</blockquote></div><br></div>