From: "Andrew P. Lentvorski" <bsder@allcaps.org> > How do you reconcile the range of subject/observer coupling and the > complexity of the notify object? At one end, the subject sends out all > the necessary data for the observer to update its view without querying > the subject at all. At the other end, the subject merely sends out a > minimal notify and the observer has to figure out what changed. Like the GoF pattern, I had intended a minimal notify with self as a parameter; however, there is certainly merit in PyNotify(self, keyOrIndex). That would help the observer know what part of the container changed. > Do you > intend to allow this flexibility or do you intend to impose one particular > implementation? Hmm. Flexibility would be great; however, I should really start with the simplest possible implementation as a proof-of-concept and to see how it is received. > While I would love a formalized, reviewed set of python modules > implementing patterns, I don't understand why you would want to do this at > the C level. The normal advantage to going to C is performance. The other advantage of going to C is to make something possible that cannot be done at the pure Python level. In this case, there is currently no way to tell whether a mutuable container has changed without reviewing its entire content. > As a > rule of thumb, the observer pattern and performance are mutually > exclusive. Agreed :( I may have to implement the simplified version (GvR's idea for having only a single observer) in order to find-out for certain whether observation is cheap or expensive. Raymond Hettinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4