Arthur wrote: > If I am understanding "properties" mostly correctly, and in fact their > reason for being is to allow for a fundamental midstream redesign of a > program without alteration of that program's API, I am thinking something to > the effect that it is only possible to do the impossible in half-measures, > and half-measures are only half-measures and who wants to work in an > environment of half-measures. > > I don't think mathematical notation, for example, includes the concept of > the half-measure.
OK, how about this explanation. If I am providing software support to a group of scientists running experiments, I can give them an API and the fastest-to-write code that passes tests. Once I've done that, they can get to work using the software while I go about the work of making the software more reasonably designed and responding to efficiency problems that they actually encounter. We use the API as a "treaty point" -- they stick to using it, and I stick to providing it. This structure can also be used to provide the "for free work-alike" and the "pricey efficient" versions. Properties allows me to determine later (perhaps after watching how they actually use the API) whether I should precalculate the triangle angles, recalculate them each time, or find an even fancier version where I compute them each the first time on demand and re-use those results, invalidating the angles whenever a side is changed. If I have to make those design decisions up front, I have to assume a pattern of use. If I wait until I have actual users, I can get real statistics on how the use the API. We decouple our work this way. --Scott David Daniels [EMAIL PROTECTED] _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
