I realise that we never have "immutable with a capital I", hence why I used the term "purely functional" to try work around the ambiguity [1]. But the point is that Chris thinks that all Numbers behave like SmallInteger, Boolean and Point in that they are, indeed, "immutable by convention". It sounded to me like Levente was saying that this was not true. If there are Numbers that are not "immutable by convention" we should _make_ them immutable by convention ASAP!
frank
[1] "Immutable with a capital I" requires VM support, IIRC
On 26 November 2013 22:45, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
What Levente says is that this immutability is purely conventional and not guaranteed. Numbers are technically mutable (but SmallInteger). Though, I strongly suggest to not play with such mutations, a mutant Number would be a frightening thing mathematically speaking...
2013/11/26 Frank Shearar frank.shearar@gmail.com
On 26 November 2013 18:02, Levente Uzonyi leves@elte.hu wrote:
On Tue, 26 Nov 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.821.mcz
==================== Summary ====================
Name: Kernel-cmm.821 Author: cmm Time: 26 November 2013, 10:24:26.281 am UUID: 591c1ede-81bc-40d7-8591-af7fe29b2bd5 Ancestors: Kernel-fbs.820
- Don't let Boolean and Number inherit Object's really slow
#veryDeepCopy.
Some Numbers are mutable objects, so this doesn't sound right.
Which Numbers are mutable? They _should_ all be purely functional, like Point (which I know is not a Number).
frank
Levente
=============== Diff against Kernel-fbs.820 ===============
Item was added:
- ----- Method: Boolean>>veryDeepCopy (in category 'copying') -----
- veryDeepCopy
"Overridden for performance to avoid #fixDependents."^ self!Item was added:
- ----- Method: Number>>veryDeepCopy (in category 'private') -----
- veryDeepCopy
"Overridden for performance."^ self!