On Jul 16, 2014, at 11:58 AM, Konrad Rosenbaum <kon...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development