Hi Gunnar Ok - setQProperty was a bad idea.
Thank you for finding that bug in the groovy bug system - I'm embarrassed I didn't check there myself. I hope that they will be able to deal with the issue. I must say, however, that setProperty and the whole concept of dynamic properties (which I approve of) is not an API issue but a language issue. At the risk of following one bad idea with another - how about setDynamicProperty instead of setProperty. While this has a disadvantage in terms of length I think it has a couple advantages. 1. setProperty IS generic as you mentioned - those not used to using dynamic properties may skip over this feature never realizing it's power - my first thought was that it was just a different way to set existing properties of an object, possibly put there to accommodate different programming styles 2. I think the code is easier to read if the method name makes it clear that we are dealing with a dynamic rather than an intrinsic property of the object. Todd. Gunnar Sletta wrote: >> Thanks for the reply. >> >> May I humbly suggest that setProperty be changed to setQProperty as >> this would seem to be consistent with other naming in Qt. > > Hi Toddy, > > Changing setProperty -> setQProperty would make the API very > inconsistent, and is not an option. Its called setLayout, rather than > setQLayout(), for instance, as the first one is easier to read. > > The real problem here is that Groovy makes the assumption that > overriding a method named setProperty() / getProperty() is ok. Given > that these names are very generic and likely to be used in any > framework, I can't understand that Groovy thinks this is an ok thing > to do. Other scripting API's normally prefix their "special" functions > with some "magic" to avoid nameclashes like this, like for instance > "__py_" or "js". > > When I dug in their bug database, I found this task: > > http://jira.codehaus.org/browse/GROOVY-2326 > > Its the exact same scenario, although with the get function. Its > marked as fixed, but is still broken, so I filed a bugreport to reopen > the task. > > So, long story short. We consider this to be a bug in Groovy, and will > not compromise our API to support it. > > best regards, > Gunnar > _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
