properties and get/set methods

[Mike C. Fletcher]

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
      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.

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

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/