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
