I know the compiler is smart enough in most cases, and even if it isn't, an extra send or two won't hurt me in the kind of computation I do.

But it's the style what "worried" me the most.

Let's use the first then :)


Esteban A. Maringolo

2017-08-05 19:18 GMT-03:00 Paul DeBruicker <pdebruic@gmail.com>:
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.