properties and get/set methods
Mike C. Fletcher
mcfletch at rogers.com
Sun Apr 6 17:41:46 CEST 2003
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.
>Well, I suppose since this is Sunday, it's appropriate to bring
>religion into it.
Well, unless you're Jewish, Muslim, Atheist, Hindu, Buddhist, or any of
the other faiths where Sunday is largely irrelevant ;) .
Seriously though, yes, this is a "religious" argument. The morality
going along these lines:
* Needless duplication of code creates bugs and increases
* 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.
As with all religions, feel free to join or not to join :) .
Unity in diversity and all that.
And, heck, we need a good lynching once in a while,
keeps the blood fresh better'n leaches ;) :D .
Feel the Fizz ;) ,
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Python-list