[Qt-jambi-interest] Jambi with Groovy

[Todd Weiler]

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
>