On Tue, Apr 16, 2019 at 5:41 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 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!
>

Maybe it's time to clean that up? Any takers? :)

Fabio


>
> 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/20190429/6356aba6/attachment.html>