Declarative properties

[Bruno Desthuilliers]

Artur Siekielski a écrit :
> On Oct 11, 4:21 pm, "sjdevn... at yahoo.com" <sjdevn... at yahoo.com> wrote:
>> In practice, it turns out to be a lot less work to deal with that
>> occasionally than to always deal with lugging around internal
>> attributes and external properties when they're really not needed.  By
>> writing everything as properties up front you're just creating more
>> work for yourself, and it's generally considered bad practice in
>> Python to have default getters/setters (whether part of a property or
>> not).
> 
> Ok, I appreciate your and Marc's argument. So I see that a pythonic
> way is
> using public attributes, and it works in real life.

Indeed !-)

> Automatic
> "generation" of
> getters/setters is a nice thing when using Java style of properties,
> ie. no
> public fields.

Java doesn't have computed attributes, so you have no other choice if 
you want to keep your design flexible. For languages that have computed 
attributes, this is not a problem to use plain attributes until you 
*really* need to do otherwise.

>>> 2. Properties define (a part of) public interface of a class. When
>>> using fields for public
>>> access, you must tell this explicitly in documentation, or use name
>>> convention.
>> Property vs. attribute doesn't make any difference here: both of them
>> are public, and part of the external interface, unless they're named
>> with a leading underscore.
> 
> Nice thing about properites is that they are defined in more
> declarative way -
> in class body. Attributes are "defined" in a piece of code (which can
> be long
> and can contain loops etc.) by assigning a value to 'self'.

Usually, all there is to know is readable in the initializer. And I've 
rarely seen (good) code that defines public attribute elsewehere (i've 
seen such a thing on a couple occasion, and that's bad coding IMHO).

Anyway, since attributes (including methods, class etc...) can be 
added/replaced/deleted by anyone having access to the object at any 
point of the program, using properties won't help that much here IMHO. 
Not that I don't see your point - I also have a taste for declarative 
APIs and readability - but this is enough to justify the use of 
properties IMHO.