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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
