[Development] Converting types in Qt

[Ziller Eike]

On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum <konrad at silmor.de> wrote:

> On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
>> Olivier Goffart wrote:
>>> It's always a dilemma. We have to look at how likely we are to break
>>> applications and I don't think adding a conversion is likely to cause
>>> breakages.
>> 
>> Type safety is a safety net that catches errors very early in the
>> software production and deployment cycle, and one of the features
>> that makes a programming language usable for the development
>> of large applications at a reasonable pace.
> 
> I feel I need to clear up some misconceptions here: the kind of type safety 
> offered by C++ is a possibility, but not a necessity for fast and safe 
> development of large applications. I've done Smalltalk for quite some time - 
> it does not have a static type system like C++ and development is still 
> faster than in most C++ based environments - I'd even go as far as saying it 
> is slightly faster to develop with Smalltalk than it is to develop with Qt 
> (I still prefer Qt for its more modern API). The key is usually great 
> documentation, good tooling, good APIs and fast turn-around from adding a 
> few lines to seeing them in action (in the last point C++ can't even hope to 
> compete with Smalltalk, the other three are quite good with Qt).
> 
>> Implicit type conversions kill type safety. This is widely recognized
>> as a bad thing. In case of C++ some are "unavoidable" due to the
>> C legacy, but e.g. for user-defined conversion operators we now got
>> "explicit", _because_ people learned the hard way that implicit
>> conversions are causing more trouble than wanted.
> 
> Let's not mix up too much here: type conversions are necessitated by the 
> fact that C++ has static typing - otherwise you would not get much done with 
> it - from the Smalltalk point of view C++ is not polymorphic. Implicit type 
> conversions are necessitated by the fact that programmers (like me) are lazy 
> bastards and don't like to read lines which are longer than a couple of 
> words.
> 
> The explicit keyword is just a way of telling the compiler that a 
> constructor is NOT a type conversion - however, I'm not entirely sure 
> whether it was such a brilliant idea to have two kinds of implicit user 
> defined conversion (constructors and type operators). 
> 
> So, just get used to the idea of prefixing each constructor with an 
> "explicit" and only consider removing it again afterwards.
> 
>> This is a kind of "convenience" I don't need, and I pretty much prefer
>> the inconvenience of having to spell out type conversions explicitly.
> 
> Reminds me of the early days of Java - almost every cast was explicit and 
> you wrote endless lines of casts just to get a very simple resource.
> 
> Thanks, but no thanks.
> 
> In short: you need a certain amount of convenience to not hinder the 
> programmer. Too much magic in the background and it is just as bad. The 
> difficulty seems to be to define the ideal point between convenience and 
> shooting yourself into the foot all the time.
> 
> As long as QVariant mirrors the abilities of C++ (i.e. only using implicit 
> conversions that are also available in plain C++, plus maybe a few very 
> obvious ones, like toString) we are fine. More and we'll get weird bug 
> reports, less and programmers will constantly bitch about it.
> 
> BTW: you can already implicitly cast QByteArray->QString, so why not allow 
> it through QVariant?

This can be considered an API fail, which is why you can explicitly turn off these type of conversions for your applications by defining QT_NO_CAST_TO_ASCII QT_NO_CAST_FROM_ASCII (which we e.g. do for Qt Creator).

Br, Eike

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B