On Mon, 2008-10-27 at 16:16 +0100, Hans Meine wrote:
> If my opinion counts, I like the old syntax better; I think "explicit is 
> better than implicit" from the Zen holds here, because you just don't *see* 
> that it's a property when you read "q.monitor = True".  (From a language 
> perspective, I like the fact that it's possible to have properties, but I do 
> not see many good reasons to use them at all.)

Properties are great when you have a lot of get_foo()/set_foo()
boilerplate, where your getter might have some small logic to return a
sane default if foo is uninitialized, and the setter does some data
validation.  kaa.canvas (and candy) just screamed for properties.

When your setter does a bit more complex stuff that has side-effects,
you're treading into the realm of property abuse.  That realm is a grey
area, unfortunately, and there's a lot of disagreement.

Personally I also think that a monitor() method and a readonly
monitoring property that provides the True/False state of the monitor
makes sense and is my preference.

Jason.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel

Reply via email to