gbracha
commented
2 years ago My latest thinking on this is that rather than define transient as a language feature, it may be better to define a concept of lazy slots, and use metadata to describe transient slots.
A lazy slot would be defined by prefixing it with lazy. It would require an initializer, but would be initialized to nil, and at first access, the initializer would be evaluated and the slot would be set to the result. In other words,
lazy slot = e.
would be roughly equivalent to
slot_x, where slot_x is an invalid identifier, and method
slot = ( slot_x isNil ifTrue: [slot_x:: e]. ^slot_x )
Note that lazy slots are not defined in the scope of the factory method.
If we actually want a transient slot, we'd write
( :transient: ) lazy slot = e.
The metadata would describe the following slot declaration, which would be treated as transient by the persistence/sync mechanism. It would warn if the slot was not lazy, since that would cause failure upon sync, since it would not be initialized. We should resist any temptation to have the metadata induce laziness, as this conflates metadata and runtime semantics.
The advantage of this design is that there are many cases where lazy initialization is needed, irrespective of persistence, and we are currently forced to implement it manually. This makes laziness independent of transience (but not vice versa, as transient slots must be lazy).
As the old Squeak version did. They are needed long term of orthogonal sync, but also for implementing images and most immediately, for improved liveness. Every cached slot should become a transient one, and every time it's code is redefined, the slot should be nil'ed (as with sync) and the data will be be recomputed - ensuring instant live update.