Smalltalk › Pharo › Pharo Smalltalk Users

Lazy vs eager initialization

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 6 messages Options
sergio_101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Lazy vs eager initialization

sergio_101
If a model has a list of things.. such as a user that can/may have lots of pets, are there any real benefits to initializing the list of pets lazily?

like:

self pets := OrderedCollection new.

vs.

pets
 pets ifNil: [self pets: OrderedCollection new]
 ^ pets

thanks!

----
peace,
sergio
photographer, journalist, visionary


signature.asc (849 bytes) Download Attachment
NorbertHartl
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Lazy vs eager initialization

NorbertHartl


Am 29.05.2018 um 17:49 schrieb sergio ruiz <[hidden email]>:

If a model has a list of things.. such as a user that can/may have lots of pets, are there any real benefits to initializing the list of pets lazily?

like:

self pets := OrderedCollection new.

vs.

pets
 pets ifNil: [self pets: OrderedCollection new]
 ^ pets


Lazy initialization is good if you only want to assign additional objects when needed. So if it would be a storage optimization you could make it in a way that only those who have pets get a collection assigned. 
The downside is on the one hand that it raises concurrency problems because if two processes call #pets at the same time it could be that two collections are created and the two processes have each one of them and only one is stored in the pets holder. On the other hand lazy init makes you use the getter even inside the object (to assure the collection is created). I usually like to avoid having getters if not really needed but a lazy init style makes this a (bad) habit. 

So my advize would be that if you don’t have a reason to do so make the initialization of this collection in the #initialize method and use the instVar accessin the methods of the pets holder. Try not to have a getter for the pets collection

Norbert
sergio_101
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Lazy vs eager initialization

sergio_101
This makes sense.. in the the cases i am writing now, all objects will, by definition, have a bunch objects in the collection..

Thanks!



On May 29, 2018 at 12:02:53 PM, Norbert Hartl ([hidden email]) wrote:

Lazy initialization is good if you only want to assign additional objects when needed. So if it would be a storage optimization you could make it in a way that only those who have pets get a collection assigned. 
----
peace,
sergio
photographer, journalist, visionary


signature.asc (849 bytes) Download Attachment
Ramon Leon-5
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Lazy vs eager initialization

Ramon Leon-5
In reply to this post by sergio_101
On 05/29/2018 08:49 AM, sergio ruiz wrote:
> If a model has a list of things.. such as a user that can/may have lots
> of pets, are there any real benefits to initializing the list of pets
> lazily?

Yes, there's a huge benefit to lazy initialization; it's more resilient
to class changes in the face of deserilization of old class shapes.  If
you add new instance vars to a class, and then deserialize older version
those instance variables will be nil.  With lazy init, this is not a
problem.  Without lazy init, this is a null ref exception.

These old versions could be from a cache of data from the previous
version of the code.  It's no fun to have to lose all cache data just
because you push out a new version of the code.

In of the face of persistence, i.e. serialized versions of your objects,
lazy init is the way to go.

--
Ramon Leon


Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Lazy vs eager initialization

Ben Coman
In reply to this post by sergio_101
While protoyping in a "live" system like Pharo, you often may add a new instance variable to existing object, 
the value of which is "nil" and may break the associated behaviour you next add.  
To deal with that you either have to sprinkle ifNils: around your code,
or alternatively do it in one location with lazy initialization.

So in general, lazy initialization is good for prototyping.
Once you're past prototyping there might be some advantage to refactoring away from lazy initialization.

cheers -ben


 

On 29 May 2018 at 23:49, sergio ruiz <[hidden email]> wrote:
If a model has a list of things.. such as a user that can/may have lots of pets, are there any real benefits to initializing the list of pets lazily?

like:

self pets := OrderedCollection new.

vs.

pets
 pets ifNil: [self pets: OrderedCollection new]
 ^ pets

thanks!

----
peace,
sergio
photographer, journalist, visionary
NorbertHartl
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Lazy vs eager initialization

NorbertHartl
+1

Norbert

Am 30.05.2018 um 05:20 schrieb Ben Coman <[hidden email]>:

While protoyping in a "live" system like Pharo, you often may add a new instance variable to existing object, 
the value of which is "nil" and may break the associated behaviour you next add.  
To deal with that you either have to sprinkle ifNils: around your code,
or alternatively do it in one location with lazy initialization.

So in general, lazy initialization is good for prototyping.
Once you're past prototyping there might be some advantage to refactoring away from lazy initialization.

cheers -ben


 

On 29 May 2018 at 23:49, sergio ruiz <[hidden email]> wrote:
If a model has a list of things.. such as a user that can/may have lots of pets, are there any real benefits to initializing the list of pets lazily?

like:

self pets := OrderedCollection new.

vs.

pets
 pets ifNil: [self pets: OrderedCollection new]
 ^ pets

thanks!

----
peace,
sergio
photographer, journalist, visionary
Free forum by Nabble Edit this page