------ Original Message ------
From: "Thiago Macieira" <thiago.macie...@intel.com>
To: development@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é
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
