Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: ... > > an extension that allows the programmer to specify how the value of > > some slot (Lisp lingo for "member variable") can be computed. It > > frees the programmer from having to recompute slot values since Cells ... > I have not looked at Cells at all, but what you are saying here sounds > amazingly like Python's properties to me. You specify a function that > calculates the value of an attribute (Python lingo for something like a
You're right that the above-quoted snipped does sound exactly like Python's properties, but I suspect that's partly because it's a very concise summary. A property, as such, recomputes the value each and every time, whether the computation is necessary or not; in other words, it performs no automatic caching/memoizing. A more interesting project might therefore be a custom descriptor, one that's property-like but also deals with "caching wherever that's possible". This adds interesting layers of complexity, some of them not too hard (auto-detecting dependencies by introspection), others really challenging (reliably determining what attributes have changed since last recomputation of a property). Intuition tells me that the latter problem is equivalent to the Halting Problem -- if somewhere I "see" a call to self.foo.zap(), even if I can reliably determine the leafmost type of self.foo, I'm still left with the issue of analyzing the code for method zap to find out if it changes self.foo on this occasion, or not -- there being no constraint on that code, this may be too hard. The practical problem of detecting alterations may be softened by realizing that some false positives are probably OK -- if I know that self.foo.zap() *MAY* alter self.foo, I might make my life simpler by assuming that it *HAS* altered it. This will cause some recomputations of property-like descriptors' values that might theoretically have been avoided, "ah well", not a killer issue. Perhaps a more constructive approach would be: start by assuming the pseudoproperty always recomputes, like a real property would; then move toward avoiding SOME needless recomputations when you can PROVE they're needless. You'll never avoid ALL needless recomputations, but if you avoid enough of them to pay for the needed introspection and analysis, it may still be a win. As to whether it's enough of a real-world win to warrant the project, I pass -- in a research setting it would surely be a worthwhile study, in a production setting there are other optimizations that look like lower-hanging fruits to me. But, I'm sure the Cells people will be back with further illustrations of the power of their approach, beyond mere "properties with _some_ automatic-caching abilities". Alex -- http://mail.python.org/mailman/listinfo/python-list
