properties and get/set methods

[John Roth]

"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message
news:mailman.1049643850.17962.python-list at python.org...
> John Roth wrote:
>
> >"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message
> >news:mailman.1049604615.22077.python-list at python.org...
> >
> >
> ...
>
> >>In these cases, you're using properties to simplify the modelling of
> >>domain objects, or to provide some *generic* functionality over and
> >>above a regular value get/set.  You don't want to have to specify
that
> >>functionality for every property, you just want to say "this is one
of
> >>_those_ properties".  The code bloat (not to mention mindless
> >>duplication of code) when you get up to 15 or 20 properties for an
> >>object would be ridiculous.
> >>
[snip]
> >>
> Seriously though, yes, this is a "religious" argument.  The morality
> going along these lines:
>
>     * Needless duplication of code creates bugs and increases
>       maintenance costs
>     * Explicit is better than implicit
>     * Practicality beats purity, but value purity when you find it
>     * Beliefs change
>
> Properties as they were originally designed have a "canon" of use
which
> says they're for wrapping getter/setter methods up into objects that
> mediate access to an attribute via x.y notation.  That's fine.  It's
> useful sometimes, though not spectacularly often in my experience.
>
> When people start using properties heavily, the definition migrates
> closer to "describing a property/attribute slot of an object" with the
> access mediation of getter/setters being a side-effect of that
> description.  So after a while, the people using them start seeing
them
> in a different light than those for whom they are still just for
> wrapping getter/setter methods.
>
> The generic characteristics and systemic functions of these new
> properties get captured in the new systems (e.g. as sub-classes of
> property objects) in such a way as to dramatically simplify some types
> of programming.  For some, the new properties *become* the interface
to
> the canon as they are the only property type used in day-to-day
> programming.  In response, the canon of "properties" either expands to
> embrace the new usage, or fractures/is redefined.
>
> Just an example...
>
> class ElevationGrid( nodetypes.Geometry ):
>     PROTO = 'ElevationGrid'
>     zDimension = field.newField( 'zDimension', 'SFInt32', 0, 0)
>     xSpacing = field.newField( 'xSpacing', 'SFFloat', 0, 0.0)
>     creaseAngle = field.newField( 'creaseAngle', 'SFFloat', 0, 0.0)
>     normal = field.newField( 'normal', 'SFNode', 1, node.NULL)
>     solid = field.newField( 'solid', 'SFBool', 0, 1)
>     ccw = field.newField( 'ccw', 'SFBool', 0, 1)
>     texCoord = field.newField( 'texCoord', 'SFNode', 1, node.NULL)
>     height = field.newField( 'height', 'MFFloat', 0, list)
>     color = field.newField( 'color', 'SFNode', 1, node.NULL)
>     colorPerVertex = field.newField( 'colorPerVertex', 'SFBool', 0, 1)
>     xDimension = field.newField( 'xDimension', 'SFInt32', 0, 0)
>     zSpacing = field.newField( 'zSpacing', 'SFFloat', 0, 0.0)
>     normalPerVertex = field.newField( 'normalPerVertex', 'SFBool', 0,
1)
>
> that's a node which has default-values for each field, as well as
> per-field watchability, introspection, type-checking and coercion.
> (Incidentally, each property shows up as a single entry in
documentation
> systems (not as 39 accessor methods + 13 properties)).  Sure, you can
do
> that with getter/setter methods, but... well... why?  Using property
> sub-classes is the solution that seems right to me.
>
> Mike

I agree, that's a better solution although there is one big difficulty.
The approach works quite well in Java, where you've got the ability
to declare a variable as "final." You don't have that ability in Python,
so you run the risk of someone accidentally rebinding the field rather
than
using the extra level of indirection needed to access it correctly.

Following on to this idea, would you say that the property syntax
introduced in Python 2.2 was a mistake? It should have been more
general?

John Roth