On Fri, Jan 18, 2002 at 11:01:03AM -0800, Tavis Rudd wrote: > thinking some more about the 'properties style' proposal ... > > One of the motivations for making the switch to 'properties' is to > remove the performance costs associated with all the accessor > methods. In cases where no calculations are done, 2 methods and an > underscored attribute can be replaced with a single property. > However, these 'quasi-properties' WON'T have docstrings associated > with them! True 'properties' can have docstrings, but they require 2 > methods and an internal underscored attribute. Thus, there's a > conflict between speed and docstrings.
Elaboration? There seem to be several ways to document a property. And what do you mean by quasi-property? One can argue that our current practice is quasi-properties. To create a property, you first write the get, set and delete methods (we already have the first two), then pass those and a docstring as arguments to the property() constructor. So we can do any of the following: 1) Leave the docstrings in the separate methods. Possibly more convenient when reading the source, but harder for introspection tools to find when dissecting the property. 2) Move all documentation into the property object rather than in the source methods. We'd have to put the documentation into a string variable first, or hardcode it as a constructor argument literal (ugh). 3) Have a wrapper for property() that concatenates the docstrings of the three methods, puts in section headers and separators, and passes that as the property's docstring. 4) Can properties have attributes? Functions and methods can. Perhaps we can add meta-information onto the property that way, if there's a need for that. -- -Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED]) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
