Seems like either way would have unmeasurable performance impact for your application vs the other and you should go for whats most legible/comprehensible. On that metric I prefer the first but #yolo Esteban A. Maringolo wrote
Hi there,
I have a question about lazy initialization accessor methods that always keep me thinking in terms of performance and style.
For years I did something like:
MyClass>>#property property isNil ifTrue: [ self initializeProperty ]. "It could be ifNil: as well" ^property
MyClass>>#initializeProperty "Returns the receiver, not the property." property := self foo collect: [:e | ... ].
But this made me think that maybe I'm performing extra operations, so I started doing something like:
MyClass>>#property ^property ifNil: [ self initializeProperty ]
MyClass>>#initializeProperty ^property := self foo collect: [:e | ... ]
The initialize method is often created by an "Extract Method" refactoring I do in the accesor, where I do the initial implementation.
The messages makes me think that the second implementation is "faster", but an initializationMethod returning the value instead of the receiver is a code smell to me.
I early initialize everything I know will be be used right away, but for cases it doesn't make sense.
What do you think/prefer? Why?
Maybe we could use the reified variables (slots) to implement the lazy initialization themselves :)
Best regards!
Esteban A. Maringolo
-- View this message in context: http://forum.world.st/Lazy-initialization-patterns-tp4958897p4958901.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.