[squeak-dev] implicit type coercion

Chris Muller asqueaker at gmail.com
Tue Apr 16 01:40:19 UTC 2019

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).

More information about the Squeak-dev mailing list