August 4, 2020



If you evaluate the following code in LearningWorks.

| myFloat yourFloat |
myFloat := 3.1.
yourFloat := 3.1.
myFloat == yourFloat

You will find that it answers false.

| myFloat yourFloat |
myFloat := 3.1.
yourFloat := myFloat copy.
myFloat == yourFloat

Also answers false.

This clearly establishes that floats are not unique. But this is an implementation issue, because in some Smalltalk systems I believe that
3.1 == 3.1
will answer true. In LW this is not the case and each time a float is evaluated, and hence needed, a new one is generated. The versions that answer true keep a list of literals and reuse as and when needed. Don't ask me which versions do this because I don't know, but I have read that this is the case.

In LB21 discussion 13 it states:

"In the expression 3.1 == 3.1 there are two 3.1 objects and each object 3.1 is an instance of Float and is not immutable. Hence the expression returns false as there are two different objects. Evaluating 3.1 = 3.1 will return true."

Well I reckon that this is wrong and that floats are immutable, even if you can copy them. Copies of floats are not the same object, but I think that M206 gives a misleading view of immutability and one of the reasons for this is that it appears to be linked to uniqueness.

I have spoken with a colleague who has this take on Smalltalk. He stresses, and I agree, that it takes a very cooperative approach. By that I mean that programmers should act within a certain spirit and if something is proclaimed as immutable then we should respect that. It's certainly possible to subvert this and with floats he claims that you could undermine the system. He gave me the code to do this, but I am not about to divulge (maybe another time). But he started with:

x := 3.0
"code omitted"
"'ll find that x is now 2.76563. My guess (I ain't no guru) is that this is just hacking away at the binary representation of the number. But, using the (cooperative) public protocol of Float, I think its instances are immutable."

In Block 4 you will look at symbols. For me M206's claim that symbols are immutable is a thorny issue, as I could go on to show by use of the basicAt:put: message selector (see the Word doc Smalltalk Traps and Bugs). A simple word of warning though, don't!
M206 when discussing symbols states that:

"once created they cannot be changed."

That is simply not true. But again you could say that the spirit is, "Look, we need to treat them this way because if we don't then all hell will break loose". The Course Team could have told the truth and said that symbols appear to be immutable, before giving a brief outline of Smalltalk's cooperative nature and illustrating how a programmer, who doesn't play ball, can destroy the system.

« Back to FAQ page
























Up to top of page