Brian Palmer wrote:
> 
>> One limitation, in comaprison with your idea: you can't add unlimited 
>> observer code--you can only add one observer per observing object, per 
>> pattern. (Each observable attr has a hash that maps [observer, 
>> pattern] => proc.) I tend to think this is sensible, but YMMV.
>>
> seems a reasonable enough limitation :)  I tend to think of the Observer 
> Pattern in terms of what your library calls signal methods rather than 
> your observable methods, but I think that's just my Java/.NET background 
> talking.  I really like the way you've done it, I may find use for your 
> library in my own projects.  Thank you.

Thanks. I've tended to use the signal methods less than the others, but 
in your example it would make more sense to use a signal for the 
keypress event. Using a signal, there is no need to define the no-op writer.

The main place I've used observable attrs in is FoxTails (on RAA), which 
is an add-on to Fox/FXRuby. Observable attrs are the basis for an 
alternative to FXDataTargets.