On terça-feira, 19 de março de 2013 15.02.35, Olivier Goffart wrote: > On Monday 18 March 2013 07:49:07 Thiago Macieira wrote: > > We are talking about it. > > As the one who says "-2", you are the one who is supposed to state your > objections.
I did. I said I wanted to discuss this more before it went in. I said waiting for 5.2 would be better. It was implied that we need more testing and more understanding of the consequences. > > Can you tell us more about the long-term plan? > > At first, it is an experiment to see what we can do. When do you plan on making it non-experimental? > It can be used in applications code for internal classes. > > Then we can see how we can do to have the generated code installed and > working. > > > What do you plan on documenting? What can people depend on? > > Good point. The documentation is still missing. Indeed, but that was not my question. I wasn't asking if you were planning on documenting or when. I was wondering what details you were planning on documenting so that people could use, and what details you'd keep private until we have a better understanding. > > Will you make moc's output files respect source- and binary-compatibility? > > Yes, this need changes. > > We will have to split the generated file in two part. One that is included > by the header containing the QObject, and one that is just linked with the > code like the current code. Peter's patch already does that. > We will also have to see which symbol need to be exported and how to do > that. (Symbols like qt_meta_stringdata_XXX and qt_meta_data_XXX will have > to be exported) Those methods are static. Exporting them is probably a bad idea. > We currently rely on the QMetaObject's revision to know at runtime which > version of moc was used. But in the case where some code stays inlined with > the application, we will have to consider that even newer metaobject may > still have an old qt_meta_call implementation. Note that as merge-at-runtime objects, you may get the string table from one implementation and the methods from another. Please take a moment to consider the consequences of this. > Then the main question is weather this is all worth it? Do we want to > support templated QObject? Indeed, good questions. > It is perhaps not that useful. But there are some good use cases still. The > intemview-ng needed to work around it. QFutureWatcher as well. > One of the often heard criticism of moc is that it does not handle template > objects. I think it is worth trying. > > Now the problem is that templates are mostly useful in libraries. And should > we support template object if we don't support them yet for libraries? I'd > say yes, it is better than nothing. And we can see if there is good use > cases. And I welcome you for trying so we can learn more. You should blog about it, saying you're experimenting. I'll be happy to look into it too. That doesn't mean the code needs to go into Qt 5.1. In fact, everything you've said so far is a clear indication it should not go into 5.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
