[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Thiago Macieira]

On Thursday 15 October 2015 21:02:09 Bubke Marco wrote:
> Actually I think Qt is not main developing library people use. It is there
> to make the boring stuff easy, to hide the different interfaces between
> different platforms. That is why many people use Qt,  they want to have a
> GUI but don't want to invest to much time in it. The interesting stuff 
> which is differentiating you from others is mostly home grown in connection
> with much more specialized libraries. And this libraries are much more
> important to the users. So we should support them, their interfaces and not
> force our interfaces on them. 

That's a slippery slope. If we have to support every library's interface, 
we'll have a horrible mish-mash of an API that tries to support everything and 
doesn't support anything really well.

I'd rather we supported the "One Qt Way" really well. Supporting other ways is 
possible, as long as we don't cause too much maintenance trouble.

> How many users use the standard library too, 
> especially the new features, why don't we support them not much better. Why
> do we have to reinvent the wheel again and again. 

I won't bother repeating the arguments of why we can't use some of the 
standard library features. And see the discussion on std::chrono as a 
replacement for QTime(Span).

> I know binary
> compatibility is important for you but is it really that important outside
> of the special linux distribution cocoon. 

Yes. Lots of users don't recompile the world when Qt issues a new release, but 
still try to upgrade.

And besides, if we have to maintain binary compatibility for 99% of the API 
anyway because of Linux distributions, then we might as well go the extra mile 
and keep it for everyone.

> Is it important under Windows, 
> is it important under Mac, is it important under embedded Linux? I think
> the advantages are smaller than the drawbacks.

I disagree.

Not to mention that "embedded Linux" these days is not different from "regular 
Linux". Even devices with 32 MB of RAM have package managers and install 
software from a central repository.

> > That's one of the two main advantages of native code. There's no sandbox
> > to
> > escape from.
> > 
> > Qt already supports doing locale-aware comparison. We even have a class
> > for
> > it, so it can be done efficiently: QCollator and it supports our native
> > string type (QString).
> 
> Do you like to live on a native island?

Yes. I love writing native code. That's one of the biggest powers of Qt 
compared to any other cross-platform solution out there. So, yeah, native 
island is good.

Did you mean to ask if I like constraining myself to only Qt-style APIs? The 
answer is also yes. I hate the Standard Library API because it's confusing (to 
me, obviously not so much to the people who wrote it), limited in convenience 
forcing me to write more code than focusing on getting stuff done. I often feel 
that the Standard Library tries to achieve 100% support of some tiny feature, 
overengineering it and not focusing on making developers' lives easier. The 
example is std::chrono.

> > Providing extra support for a character encoding that is not what QString
> > uses falls in that 1%. Just use ICU.
> 
> You arguments sounds very tautological. Because it is unimportant we don't
> have it a string class for it. It is unimportant because QString is not
> supporting it.

You're misrepresenting the argument. QString doesn't support other encodings 
because UTF-16 is the best for the task at hand and we have too much legacy to 
support. Because of that, QCollator only supports UTF-16.

> I know you love plationian argumentation but it would be much more effective
> if you would try to get in the context of other and understand their
> arguments in their context.  Showing in your own context that their
> arguments "makes no sense" is not very useful.

You're dangerously close to attacking me instead of attacking my arguments.

> > That example shows how UTF-16 is better. See above on seekability of
> > UTF-16 vs UTF-8.
> > 
> > The solution for this is to fix the library to accept UTF-16. When we were
> > doing Qt 5.0, we needed PCRE to support UTF-16. Their developers were very
> > welcoming and wrote the version that supports UTF-16, so Qt does not need
> > to reallocate.
> 
> You have ever heard of Pippi Longstocking: "Widdiwiddiwitt, we make the
> world like we wish it should be. "  or how it is translated to english. You
> really think that you can force other larger projects to use utf16 instead
> of utf8 if it has disadvantages for them.

And why should we support UTF-8 instead of UTF-16 if it has disadvantages for 
us?

We'll have to agree to disagree with those projects. We've chosen UTF-16 and 
we're aligned with a lot of other important API.

> And the PCRE is now supporting both at  runtime? Especially for large text
> it would be very helpful if you don't need to convert them to QString
> before you use  regular expressions on it.

As far as I know, it operates entirely on UTF-16 in memory if the input was 
UTF-16.

> > Way too much code would break if we did that because we allow people
> > access to the data pointer in QString and to iterate directly
> > (std::{,w,u16}string don't allow that, which makes parsing them actually
> > a lot more cumbersome).
> I don't see the disadvantage if you have special iterators. 

As long as QString contines to be backed by UTF-16, providing iterators is 
fine. In fact, we have an iterator for UCS-4: it's called QStringIterator and 
has been there for a year.

> That is the
> power of iterators and with the new features of C++ they get really useful.
> But anyway,  I don't say that we have to change everything. The last time
> we did that we broke our event system which is still not working like it
> was before we introduced QWindow. I think we  should have an evolutionary
> process to  adapt to the  changing environment and not try to reiterate
> what was successful in the past.

I agree with what you said in this paragraph. But it does not lead to a 
conclusion about using UTF-8 or even providing our own UTF-8 class.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center