[PEAK] Automatic 'Obtain' attribute deletion

[Phillip J. Eby]

At 06:59 PM 9/28/04 +0200, jdutreve at free.fr wrote:
>Hi all,
>
>I'm learning the possibilities of component bindings and
>I wonder if PEAK could automatically delete all 'Obtain' attributes
>as soon as their 'Make' counterpart is re-computed.

No.  I don't currently intend to add something like this, either.  The 
configuration system is intended for settings that remain stable throughout 
a component's lifetime.  Adding automatic updates would make the system a 
lot more complex, but only benefit a small set of applications.

However, you can extend the system yourself, by implementing custom 
subclasses of binding.Attribute.  If I were implementing it myself, I'd 
probably create a 'Publish' attribute and a 'Subscribe' attribute, rather 
than using Make and Obtain, because the required operations are so 
different.  For example, you'd want to override the Attribute.onSet() 
method to handle notifying subscribers whenever the value is set.


>So that these attributes can be up to date for the next access,
>then cached until the next 'Make' computeValue(), without
>deleting manually all of them.
>
>Currently, I only know the noCache Attribute parameter which
>recompute at each access, but I'm looking for an automatic
>deletion mechanism, a kind of observer/observable.

You can use various peak.events classes to handle the observation 
mechanics.  For example, you can create an 'events.Broadcaster' in the 
Publish attribute, and add a callback to it from the Subscribe attribute.

P.S.  I know it says in TODO.txt that I plan for "writable and subscribable 
config sources, including editable .ini's", but I've long ago forgotten 
what I intended to implement that *for*, or how it was that I was going to 
make it co-operate with the lazy immutability of the rest of the 
system.  So, I'm going to strike that item from TODO.txt as soon as 
practical along with the "service zones" idea, which has also worked out to 
be a YAGNI.