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.
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!
Numbers are not any more mutable than Points or Dates. They're all Value objects, regardless whether they're a Smalltalk immutable.
Even so, that's irrelevant to this change anyway because #veryDeepCopy is about enabling the Prototype pattern. The inherited implementation from Object is way overkill and way too slow for Numbers.
PS -- I even do the same for Strings in my own personal core-extensions library, which I think belongs in trunk too.
On Tue, Nov 26, 2013 at 12:02 PM, 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.
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!
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!
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!
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!
On Wed, Nov 27, 2013 at 1:51 AM, Frank Shearar frank.shearar@gmail.comwrote:
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!
Agreed. But note that there are edge cases in this apparently straight-forward case. The LargeIntegers need to be mutable while they're being constructed (they're not all constructed by primitive code and that primitive code is optional).
But on the "we will never have immutable with a capital I" point I disagree. The VM can easily enforce immutability. I actually implemented this for the Newspeak interpreter VM in 2007. It is a "small matter" of implementation to move it into Cog. It's probably two weeks work. But its not a priority yet. It might be a good thing to introduce when we move to Spur because there will be other things that will disturb too (image segments, ephemerons to be used, etc).
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!
On 27 November 2013 17:09, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Nov 27, 2013 at 1:51 AM, Frank Shearar frank.shearar@gmail.com wrote:
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!
Agreed. But note that there are edge cases in this apparently straight-forward case. The LargeIntegers need to be mutable while they're being constructed (they're not all constructed by primitive code and that primitive code is optional).
OK, but that's acceptable. Just as long as once they're constructed, they can no longer mutate.
But on the "we will never have immutable with a capital I" point I disagree.
I never said that!
The VM can easily enforce immutability. I actually implemented this for the Newspeak interpreter VM in 2007.
Exactly!
It is a "small matter" of implementation to move it into Cog. It's probably two weeks work. But its not a priority yet. It might be a good thing to introduce when we move to Spur because there will be other things that will disturb too (image segments, ephemerons to be used, etc).
Indeed. Capital-I Immutability is very cool, and I do think we need it in the long run (along with a bunch of other goodies like decent purely functional data structures), and we'll get there sooner or later. Other things first though.
frank
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!-- best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Eliot Miranda -
Frank Shearar -
Levente Uzonyi -
Nicolas Cellier