[Glass] Class var and class inst var caches in libraries

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Tue Oct 4 12:21:15 PDT 2016


Yes, lazy initialization for shared variables in a multi-gem system is 
not a good idea.

Since it sounds like you do not need the values persisted and shared 
between gems, you should be using the class SessionTemps. Here's an 
example from Collection class>>randomForPicking:

randomForPicking
   | random |
   random := SessionTemps current
     at: #'COLLECTION_RANDOM_FOR_PICKING'
     otherwise: nil.
   random == nil
     ifTrue: [ random := Random new.
       SessionTemps current at: #'COLLECTION_RANDOM_FOR_PICKING' put: 
random ].
   ^ random

SessionTemps is a subclass of SymbolDictionary and can be used for 
storing session-specific globals.

If you have the need to sharing persistent values then an explicit 
initialization in the class initialization method is the right answer. 
The initialize method gets run during install and at least the 
initialization is safe from commit conflicts.

Dale


On 10/04/2016 11:56 AM, monty via Glass wrote:
> Lots of libraries use caches stored in class vars and class isnt vars that are either explicitly or lazily initialized. But with multiple Gems accessing the same repo, this can produce write-write conflicts. In fact, simply sending #initialize to the same class from different Gems can cause them. What are the best ways to implement these caches in GS? Write-locks seem like overkill, so I'm interested in simple ways of making them non-persistent.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass



More information about the Glass mailing list