<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 5:41 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 16 avr. 2019 à 10:50, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Chris,</div><div>putting messages in Object is never intelligent, at best hackish, and at worse bad style (because of littering and of such un-controlled side effects).</div><div>The purpose of my changes was to distinguish comparison from arithmetic:</div><div>- for performing arithmetic, exact + inexact lead to an inexact, so it's OK to convert asFloat.</div><div>- for performing comparison exact < inexact, you must not convert to inexact or you wll change the relation.</div><div><br></div><div>I don't remember what drove me to such high level in hierarchy, but I think that I had to cope with many objects pretending to perform arithmetic (Collection, String, ...).</div><div>Or were the original messages already at high level?<br></div></div></div></div></blockquote><div><br></div><div>Ater inspection, it's not me who decided...</div><div>All the adaptToXXX:andSend: were already at Object level since 1998!</div></div></div></blockquote><div><br></div><div>Maybe it's time to clean that up? Any takers? :)</div><div><br></div><div>Fabio</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div>We should feel free to revisit anyway!<br></div><div><br></div><div>I don't like implicit conversions when there is no well established bijection.</div><div><br></div><div>The example from Tim was excellent: should 1+$1 be 2 or 50?</div><div>Why is it different from 1+'1'?</div><div>Should we convert Boolean asInteger for cross language (in)convenience?</div><div>Should we have true = '1' then?</div><br><div></div><div>For me, this is opening a can of worms: a principle of most astonishment.</div><div>All those wanting to follow the astonishment path should first lesson once more to:</div><div>
<div> https://<a href="http://www.destroyallsoftware.com/talks/wat" target="_blank">www.destroyallsoftware.com/talks/wat</a></div>

</div><div><br></div><div>In the same vein, I hate the null pattern. nil is not false, #() and '' are not false, because empty is not false, 'false' is not true either (though not empty), etc...<br></div><div></div><div>These extensions are obscuring the intentions, are equivoque, and are delaying bug finding when un-intentional.</div><div><br></div><div>For example, in Matlab relations < and > are defined on complex: you hardly never gonna need that...</div><div>except maybe when sorting the eigenvalues of a matrix- and even in this case, you don't want to always use the same ordering,</div><div>There is no natural ordering preserving a<b & (c<d) ==> (a+c)<(c+d), so why choose one rather than the other?</div><div>The net result is that it is delaying bug finding when you have an unexpected complex result, the program continues and does something, it's just that you don't know exactly what, you lost control...<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 16 avr. 2019 à 03:41, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kudos Fabio for noticing the non-symmetry in type coercion between<br>
Strings and Characters.  I was doing a little more research and<br>
noticed we have all these adapt'ing methods on *Object* (!!).<br>
<br>
Object>>#adaptToFloat:andCompare:<br>
Object>>#adaptToFloat:andSend:<br>
Object>>#adaptToFraction:andCompare:<br>
Object>>#adaptToFraction:andSend:<br>
Object>>#adaptToInteger:andCompare:<br>
Object>>#adaptToInteger:andSend:<br>
Object>>#adaptToScaledDecimal:andCompare:<br>
<br>
Browse origin showed methods added in 2006 by Kernel-nice.398 (version<br>
notes below).  The explanation given there and in all three Mantis<br>
reports relates to coercions between Integers and Floats.<br>
<br>
So, it doesn't appear that these were intended to encourage automatic<br>
coercion of ANY object to the numbers domain for interoperation with<br>
numbers, but its presence on Object maybe was the common superclass<br>
for the implementation.<br>
<br>
I submitted an alternative version to the Inbox which proposes<br>
symmetry between Strings and Characters to be that they both require<br>
explicit coercion.<br>
<br>
Whether to do automatic coercion in the language feels like a weighty<br>
decision.  My gut is telling me its better to be conservative in doing<br>
auto coercing, but I'm sure Nicolas' and others' can better articulate<br>
an the most intelligent path forward.<br>
<br>
 - Chris<br>
<br>
_____________<br>
Name: Kernel-nice.398<br>
Author: nice<br>
Time: 13 February 2010, 4:31:00.389 am<br>
UUID: f1525362-d01a-214c-94fe-2bb3a5fffa89<br>
Ancestors: Kernel-nice.397<br>
<br>
Fix<br>
<a href="http://bugs.squeak.org/view.php?id=3360" rel="noreferrer" target="_blank">http://bugs.squeak.org/view.php?id=3360</a><br>
<a href="http://bugs.squeak.org/view.php?id=3374" rel="noreferrer" target="_blank">http://bugs.squeak.org/view.php?id=3374</a><br>
<a href="http://bugs.squeak.org/view.php?id=6601" rel="noreferrer" target="_blank">http://bugs.squeak.org/view.php?id=6601</a><br>
<br>
hash and = are now reconciled for numbers.<br>
= is now transitive for numbers.<br>
<br>
WARNING: now, tests like (1/10 = 0.1) will answer false.<br>
This is expected, and more than expected, this is wanted.<br>
Float are inexact and testing for strict equality is not a clever thing to do.<br>
All this has been longly debated at<br>
<a href="http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/10642" rel="noreferrer" target="_blank">http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/10642</a><br>
<a href="http://thread.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/10223/focus=10228" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/10223/focus=10228</a><br>
<br>
Please, read carefully this thread to make an opinion before raising your voice.<br>
It can break code eventually,  so I'm all ears to real case, and<br>
willing to help fixing. But please, real examples, not theoretical<br>
(after 8 month change in Pharo, I'm not aware of further complaints).<br>
<br>
</blockquote></div>
</blockquote></div></div>
<br>
</blockquote></div></div>