[Qt-interest] Qt5 and SQL

[Thiago Macieira]

On Tuesday, 7 de June de 2011 07:06:24 Atlant Schmidt wrote:
> Folks:
> 
>   On the other hand, it would be a better world if Thompson
>   had, somewhere along the way, changed the spelling of
>   "creat()" to "create()".

When asked what he would do differently if he had to do Unix all over again, 
Ken Thompson answered that he would add an "e" to "creat".

>   Maybe it's a little later in the game for Qt, but maybe
>   this still falls into the "But we already had 20 users!"
>   fallacy that led Thompson astray. Do you want/do you
>   expect Qt to grow? If so, then somewhere along the line,
>   one *SHOULD* remove the cruft that accumulates, especially
>   when it can be done in a perfectly upwards-compatible
>   way such as introducing a properly-named class that is
>   documented as being just the properly-named edition of
>   an older, badly-named class (or the properly spelt version
>   of a file-creation function). The people reading the old
>   E-mails will just have to deal with the change.

Properly backwards compatible is the key here.

Renaming a class isn't backwards compatible. Maybe it's easy to rename one 
class and adapt the code. But Qt right now has over 1000 classes, not counting 
the ones in Mobility. If even 5% of them require renaming and 5% of the 
methods within require some update, we'll end up in a thousand-paper-cut-
death. It will be as big a change to Qt 5 as Qt 4 was to Qt 3.

That's completely unacceptable. We'll have to make do with certain flaws for a 
while. We need to do for 5.0 only what cannot wait, the flaws that we cannot 
live with for longer. Other things we should fix as time goes by, introducing 
the new, better API and deprecating the old.

When Qt 6 comes (in 2015 maybe? no later than 2016), we can and should remove 
the deprecated cruft.

Another thing to pay attention to is that we have smaller modules. We can 
break compatibility in each module by introducing new major versions. For 
example, if the Qt 5.0 version of Qt Multimedia is numbered 2.0, it's entirely 
possible for Qt Multimedia to release a binary-incompatible 3.0 before Qt 
releases 6.0. The same applies for QtSql: it's possible to have a "6.0" 
version with a fixed API before long.

>   And yes, the broken windows analogy is very apt. The
>   theory doesn't just speak to how vandals behave, it also
>   speaks to the way the tenants behave and feel about the
>   place where they live. Just like the tenants don't think
>   well of their housing if the windows remain broken, I
>   know I'm far less likely to think well of a software
>   system, even a software system where I "live" (one I
>   use and depend-upon) if the system is full of pissant
>   bugs and defects that *NEVER GET FIXED*.

Please also note the thousand-paper-cut analogy.

At this point, I'm willing to live with a broken window if the only solution 
to that is to demolish the house and rebuild it, or move to another one that 
is away from my neighbourhood.

>   Do we know any of those (persistent pissant bugs or the
>   systems that contain them?)

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110607/3d19eabc/attachment.bin