Thiago Macieira schreef op 25-11-2013 17:23: > On segunda-feira, 25 de novembro de 2013 17:00:41, André Somers wrote: >> Thiago Macieira schreef op 25-11-2013 16:56: >>> On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote: >>>> Please note that this goes for *any* method that has an overload. And >>>> that any method that currently does not have an overload, may still get >>>> one in the future. If you don't want to run the risk of source >>>> incompatabilities in the future, I'd always use the explicit signature. >>> We'll pay more attention to this now that we are taking addresses to >>> functions. >> As in: we're not going to introduce any overloads to any public >> functions anymore? So, a hypothetical function sort() could no longer be >> overloaded to take an additional parameter like Qt::SortOrder that was >> overlooked in the first version of the API design? > Right, we will avoid adding overloads to signals whenever possible. But we > currently have no automated test for this, so we might regress > unintentionally. > > If someone has some time to add a unit test framework, it would be very > welcome. As you can connect to any method (as the slot part of the connection), would this policy then not be needed for *all* methods, not just signals? Or do I just misunderstand the impact of the issue here?
André _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
