paolo.bernardi.67 <at> gmail.com <paolo.bernardi.67 <at> gmail.com> writes:
ok: 1+1 can be optimized, but all objects in the universe that are not numbers are different.
Nicolas: what should respond: ^'6:30am' asTime class allInstances size in the scenario of my crazy-optimization?
I guess: tons of Time's, including the freezed one (6:30).
But the freezed-6:30 is always the same? Yes, otherwise it means #asTime is always-evaluated.
...not too far from pre-calculating all cos and sin values of 360 degrees and storing in two arrays of 360 elements.
Anyway I see it's a bad way...
No, it's not at all a bad way. It's a functional way. It's not native Smalltalk way, but we can try to mimic a functional style in Smalltalk. The only problem is that we won't have the guaranty of a functional programming language w.r.t. to constantness/immutability. My example allInstances is an evil statefull method accesses and returning states of current memory... And in Smalltalk there is no easy way to distinguish a statefull from stateless message. By default, all objects are stateful, but by conventions, many objects are used as if stateless. They have methods for mutating them, but these methods are used once at initialization, and only once. For example we don't modify a Float, a Point, a Rectangle, after creation, even if we could.
Note that beside the possibility to create a class variable and initialize it once for all, some other Smalltalk dialects provide various ways to express what you are after: - a "compile time" constant in Dolphin with following language extension: ^##( '6:30am' asTime ) Above expression would be evaluated when the method is accepted and memoized, then next invocations of the method just return the memoized value. - a lazy evaluation constant in Visualworks: ^['6:30am' asTime] once The result of block evaluation is memoized at first method invocation, and returned on next invocations (you must read it literally, the block is evaluated only once).
As you can see, you are not the only one missing those functional features.
Late binding is wonderful because it enables changing a living system (rather than reconstructing from scratch). Almost any part of the system can be changed (the limitation is that some are well known to the VM and cannot change that easily).
But we are not going to change Time or Float every day, so the optimization you are looking for can also make sense.