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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development