On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: > On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: > > On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz > > wrote: > > > On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira > > > wrote: > > > > I think that, despite the potential benefits of the changes, > > > > we should not apply them at this time. There are far too many > > > > chances for breakage and it's a blatant disrespect for the > > > > feature freeze. > > > > > > I assume this is meant as a verdict, not as (possibly > > > temporary) state of thinking. > > > > Correct. The changes are the right thing to do, just not now. > > We'll have to live with the current containers and their overhead > > until Qt 6. > > > > That includes the fact that QList<QVariant> is extremely > > inefficient. > > this is absurd.
Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] > we said A, now we need to say B. or "unsay" A, which i don't think > anyone wants. > > i for one don't believe in qt6 anytime soon. it's the do-never release > qt5 was for years. The suggested "4 years" are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between "current" and "patched" versions, default to "current". [This is probably the most expensive solution, but the one that fits best to "the rules"] Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development