[PEAK] very elementary peak.model question

[Phillip J. Eby]

At 02:55 PM 7/13/04 -0500, Doug Quale wrote:
>The lazy compute-once attributes provided by peak.binding are
>invaluable.  What is the best way to get this behavior from
>peak.model?

Probably to wait until I refactor it to use generic functions.  ;)

Of course, if you need to know a definite time as to when that will happen, 
you're better off with a non-"best" way.  :)

And all of this is assuming lazy attributes are what you want in the first 
place... see below.


>Clearly I can write a simple get() method that will do the query after
>checking to make sure that the value isn't already set, but that seems
>too clunky to use with a framework as elegant as peak.
>
>Maybe I'm thinking about this backwards.  It looks like when using a
>peak DM the DM would manage this as part of creating model objects,
>possibly by using storage.QueryLink().  Would it be best to not have
>model objects load themselves?  If so, what would that look like?

(My answer is going to assume you've already studied the IntroToPeak 
tutorial on the Wiki for basic DM operations, which will answer most of 
what that would "look like":.)

A DM's '_load' method can load actual attribute values into an object, *OR* 
it can load LazyLoader instances (see 
peak.storage.lazy_loader).  LazyLoaders are objects with a 
'load(ob,attrName)' method.  model.Element objects already have logic to 
notice when one of their attributes are a LazyLoader instance, and invoke 
it.  The LazyLoader must then poke whatever values it needs to, into the 
object's dictionary.

So in a sense, your hack is already part of the framework.  :)

The future direction of model and storage is going to be to define a 
'before' method for the attributes, something like:

     [before("ob in SomeClass and ws in MyWorkspace and 'attr' not in 
ob.__dict__"
             "and attr_name=='attr'")
     ]
     def get_feature(ws, ob, attr_name):
         # code to load the feature value and put it in the dictionary
         # before the normal 'get_feature' method can pull it out...

Of course, there'll probably be a shorthand way to spell this, maybe 
something like:

     [attribute_loader(MyWorkspace,SomeClass,'attr')]
     def get_feature(ws, ob, attr_name):
         # etc.

Of course, some loaders would handle multiple attributes at once.  Anyway, 
it's vastly more elegant, as the same mechanism allows for persistence, 
derived values, and binding-style cached values all in one hook function.