[Development] Converting types in Qt

[Konrad Rosenbaum]

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?


	Konrad