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.
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
Locked
