Le mar. 16 avr. 2019 à 10:50, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> a écrit :

> Hi Chris,
> 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).
> The purpose of my changes was to distinguish comparison from arithmetic:
> - for performing arithmetic, exact + inexact lead to an inexact, so it's
> OK to convert asFloat.
> - for performing comparison exact < inexact, you must not convert to
> inexact or you wll change the relation.
>
> 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, ...).
> Or were the original messages already at high level?
>

Ater inspection, it's not me who decided...
All the adaptToXXX:andSend: were already at Object level since 1998!

We should feel free to revisit anyway!
>
> I don't like implicit conversions when there is no well established
> bijection.
>
> The example from Tim was excellent: should 1+$1 be 2 or 50?
> Why is it different from 1+'1'?
> Should we convert Boolean asInteger for cross language (in)convenience?
> Should we have true = '1' then?
>
> For me, this is opening a can of worms: a principle of most astonishment.
> All those wanting to follow the astonishment path should first lesson once
> more to:
>  https://www.destroyallsoftware.com/talks/wat
>
> 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...
> These extensions are obscuring the intentions, are equivoque, and are
> delaying bug finding when un-intentional.
>
> For example, in Matlab relations < and > are defined on complex: you
> hardly never gonna need that...
> except maybe when sorting the eigenvalues of a matrix- and even in this
> case, you don't want to always use the same ordering,
> There is no natural ordering preserving a<b & (c<d) ==> (a+c)<(c+d), so
> why choose one rather than the other?
> 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...
>
> Le mar. 16 avr. 2019 à 03:41, Chris Muller <asqueaker at gmail.com> a écrit :
>
>> Kudos Fabio for noticing the non-symmetry in type coercion between
>> Strings and Characters.  I was doing a little more research and
>> noticed we have all these adapt'ing methods on *Object* (!!).
>>
>> Object>>#adaptToFloat:andCompare:
>> Object>>#adaptToFloat:andSend:
>> Object>>#adaptToFraction:andCompare:
>> Object>>#adaptToFraction:andSend:
>> Object>>#adaptToInteger:andCompare:
>> Object>>#adaptToInteger:andSend:
>> Object>>#adaptToScaledDecimal:andCompare:
>>
>> Browse origin showed methods added in 2006 by Kernel-nice.398 (version
>> notes below).  The explanation given there and in all three Mantis
>> reports relates to coercions between Integers and Floats.
>>
>> So, it doesn't appear that these were intended to encourage automatic
>> coercion of ANY object to the numbers domain for interoperation with
>> numbers, but its presence on Object maybe was the common superclass
>> for the implementation.
>>
>> I submitted an alternative version to the Inbox which proposes
>> symmetry between Strings and Characters to be that they both require
>> explicit coercion.
>>
>> Whether to do automatic coercion in the language feels like a weighty
>> decision.  My gut is telling me its better to be conservative in doing
>> auto coercing, but I'm sure Nicolas' and others' can better articulate
>> an the most intelligent path forward.
>>
>>  - Chris
>>
>> _____________
>> Name: Kernel-nice.398
>> Author: nice
>> Time: 13 February 2010, 4:31:00.389 am
>> UUID: f1525362-d01a-214c-94fe-2bb3a5fffa89
>> Ancestors: Kernel-nice.397
>>
>> Fix
>> http://bugs.squeak.org/view.php?id=3360
>> http://bugs.squeak.org/view.php?id=3374
>> http://bugs.squeak.org/view.php?id=6601
>>
>> hash and = are now reconciled for numbers.
>> = is now transitive for numbers.
>>
>> WARNING: now, tests like (1/10 = 0.1) will answer false.
>> This is expected, and more than expected, this is wanted.
>> Float are inexact and testing for strict equality is not a clever thing
>> to do.
>> All this has been longly debated at
>> http://permalink.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/10642
>>
>> http://thread.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/10223/focus=10228
>>
>> Please, read carefully this thread to make an opinion before raising your
>> voice.
>> It can break code eventually,  so I'm all ears to real case, and
>> willing to help fixing. But please, real examples, not theoretical
>> (after 8 month change in Pharo, I'm not aware of further complaints).
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190416/5dbb8b7d/attachment.html>