[Development] Possible bug in signals and slots handling in QML.

[aaron.kennedy at nokia.com]

Hi,

On 04/01/2012, at 3:29 PM, ext Thiago Macieira wrote:

> On Wednesday, 4 de January de 2012 09.42.52, Atlant Schmidt wrote:
>>  Let me more-explicitly/completely state the rule
>>  that I use:
>> 
>>    1. Always use the canonical casing for an identifier.
>> 
>>    2. Don't create any other identifiers that differ
>>       from an existing canonical identifier only in
>>       their casing.
> 
> That assumes you have an option to follow your rules.
> 
> I'm asking for consideration of the case where you *don't* have an option. 
> Mangling identifiers and magic identifier injection are really bad.
> 
> Think also of how Qt Creator or any code model needs to do to find the property 
> or signal related to "onFooBar". It cannot lowercase the the 'F' because it 
> doesn't *know* that the original identifier is "fooBar". It should search all 
> identifiers for the one that, mangled, produces the "onFooBar" handler.
> 
> The problem with this mangling is that it's not 1:1. That's why I'm calling it 
> bad.

QML is case sensitive.

We don't allow signal or property names to start with an uppercase letter, so in theory "fooBar" and "FooBar" cannot cause ambiguity with "onFooBar".  Unfortunately, I just noticed that we do allow "__FooBar" as a name, which does cause the problem :)  But that's a bug, and should be fixed.

Where a name ambiguity arises, we generally have a well defined precedence (so the resolution is stable and defined), but generally not a way to explicitly choose the alternative.  Frankly, it doesn't really come up in the real world, and complicating everything else for academic cases seems pointless.

I do like your "on fooBar" idea, but we didn't think of it (if only you'd suggested it earlier ;) and I don't think it is sufficiently better to justify changing now.

Cheers,

Aaron