[Development] Proposal to change connectSlotsByName behavior

[André Somers]

------ Original Message ------
From: "Thiago Macieira" <thiago.macieira at intel.com>
To: development at qt-project.org
Sent: 04/12/2015 03:00:15
Subject: Re: [Development] Proposal to change connectSlotsByName 
behavior

>On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
>>  I don't think it will break too many applications because anyone who 
>>was
>>  relying on the order of instentiation for that has just its 
>>application
>>  working out of pure luck. (And i'm pretty sure that your proposal is 
>>always
>>  the intended behaviour)
>
>Note that for widgets, the order is not pure luck. The order of 
>children of a
>QWidget implies the tabbing order. Therefore, it is usually 
>well-defined.
There are explicit methods for setting the tab order. Relying of the 
order of creation (which may be the default tab order - I did not check) 
is also pure luck, especially with designer-created UI's. I would think 
the connect-by-name is more used with designer created UI's than with 
hand-crafted UI.

>
>I don't mind changing the order, as long as there's a consensus in the 
>mailing
>list.
>
I am for it. I think it makes more sense than the current behaviour.

>If we do decide to change the order, I have a follow-up question:
>  do we change it only in connectSlotsByName, or do we change
>  QObject::findChildren to reflect the new order?
Both. A breath first search makes sense there as well. I don't think the 
order of the children is specified there so one should not rely on it 
anyway.

>
>Right now, connectSlotsByName simply uses findChildren's order. If we 
>decide to
>change the order in one but not the order, I'd like to hear a 
>compelling
>reason why it's ok for them be different.
>
Because that is an implementation detail. That the one uses the other 
makes it convenient for them to be the same, but the one does not _need_ 
to use the other. But in this case I think it makes sense for both to 
change. If changing findChildren is regarded as too risky though, I 
don't think that that is an argument to not change connectSlotsByName 
either.

>>  Other possibilities may include:
>>   - Connect signals of both objects.  (Probably not a good idea since 
>>it does
>>  make it even more confusing)
>
>Agreed that this is not a good idea. Let's discard it.
>
>>   - Throw a warning if there are two objects with the same name.
>
>This is orthogonal.
>
I'd like to add a new alternative (though it does not exclude a change 
now either):

- Deprecate the behaviour and remove in Qt 6.

I have never thought this feature to lead to good design. It makes for 
"magic" in the sense that it is tricky to trace what happened. It leads 
to un-Qt-ish naming of methods, and it leads to naming methods based on 
when they are triggered instead of what they do. I find the latter 
usually leads to more readable code, more so if there is more than one 
way to trigger the behaviour encoded in the method. Last, I think 
private slots (for which this would be most used) are largely on the way 
out anyway. Trivial slots can be replaced by lambda's and non-trivial 
ones need a good function name anyway.

André

>