<div dir="ltr">I am not so fond of this change. It feels like a slope towards JavaScript, which has (not so) funny articles about the ridiculous implicit type conversions. There was a change last year that disallowed putting numbers (bytes) in ByteStrings and vice versa. This change goes kind of in the other direction.<div><br></div><div>The #< of Character seems to support comparisons with numbers. But this may never have been intended as it is a side effect of how the method is implemented (comparing the #asInteger values of the Characters)? If it were implemented in terms of #codePoint instead of #asInteger, it would not support comparison with numbers, but still work for Characters.</div><div><br></div><div>Yet I see the compatibility trouble and the long history of adaptToNumber:andSend:.</div><div><br></div><div>I would prefer if people wrote more asInteger/asNumber or asCharacter if they need to ensure the types (because they expect that sometimes numbers come in instead of characters, or the other way around), instead of relying on implicit type conversions. It also forces them to think about which kind of character to number conversion they want, referring to what Tim wrote: are digit characters their number counterparts or their unicode code points?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 12. Apr. 2019 um 19:14 Uhr schrieb tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 2019-04-12, at 12:30 AM, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
> <br>
> <br>
> Just like strings, characters should convert themselves to an integer when involved in arithmetic with a number.<br>
<br>
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: LA: Lockout Access<br>
<br>
<br>
<br>
</blockquote></div>