[squeak-dev] implicit type coercion
lists at fniephaus.com
Mon Apr 29 17:58:54 UTC 2019
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
>> 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? :)
> We should feel free to revisit anyway!
>> I don't like implicit conversions when there is no well established
>> 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:
>> 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* (!!).
>>> 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
>>> 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
>>> 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...
More information about the Squeak-dev