Create a factory method for calling locations

(1:15:18 AM) tedivm: we used to store the internals as an id and i switched 
away from that because we 
ended up rebuilding the location class quite a bit
(1:15:42 AM) charlequin: the difficulty I see is basically as follows: if you 
never know how long the 
location is going to sit around storing a whole copy of its parent in memory, 
you don't know whether 
any of the location-specific info has changed since you generated it
(1:16:43 AM) charlequin: and I'm guessing that if I have to poll the database 
to check the last 
timestamp when the location was changed, I've already taken a performance hit, 
yes?
(1:17:09 AM) tedivm: Solution- create a factory method for calling locations 
and funnel all "new 
Location()" calls through it, then when can have it cache our location creation
(1:17:18 AM) tedivm: i bet that would save us a ton of resources
(1:17:48 AM) charlequin: now that does seem like an excellent idea
(1:17:50 AM) tedivm: and it would let us use dependency injection techniques to 
change the location 
system later down the line without fucking with the developers too much
(1:17:59 AM) charlequin: especially since we instantiate Locations all the 
fucking time
(1:18:06 AM) tedivm: yeah, we really fucking do
(1:18:13 AM) tedivm: more caching for the win!

Original issue reported on code.google.com by charlequin@gmail.com on 9 Apr 2010 at 5:23

tedivm / mortar

Create a factory method for calling locations #95