[Development] Abandoning the container changes

[joao.abecasis at nokia.com]

Hey,

I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. 

I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack.

Cheers,


João

________________________________________
From: development-bounces+joao.abecasis=nokia.com at qt-project.org [development-bounces+joao.abecasis=nokia.com at qt-project.org] on behalf of ext André Pönitz [andre.poenitz at mathematik.tu-chemnitz.de]
Sent: 17 July 2012 23:59
To: development at qt-project.org
Subject: Re: [Development] Abandoning the container changes

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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development