Proposal: useful return values instead of void
-
I don't think this proposal has much chance of getting through. As ChrisW67 illustrated, it will result in weird looking code either way you implement it, and compressing code on single lines isn't stimulated either.
However, I sometimes would like to have some references available to avoid stuff like this:
@
QFont f = myLabel->font();
f.setBold(true);
myLabel->setFont(f);
@It would be nice to be able to write:
@
myLabel->fontRef().setBold(true);
@and have that actually change the font for the label. However, I guess there are problems there of how the label is supposed to know about any changes made in such cases.
-
Does not necessary need to be compressed to a single line:
@
w->setName()
->setThis()
->setThat();
@I actually use this concept in my "QEasyShell":http://sierdzio.com/qeasyshell/ but for a slightly different reasons (to make code look more shell-like).
-
There should always the concept of void, it sometimes relax a "new to programming person's" mind. Anyhow suggestion is great for experts.
-
[quote author="sierdzio" date="1360318574"]Does not necessary need to be compressed to a single line:
@
w->setName()
->setThis()
->setThat();
@
[/quote]Well that kind of beats the purpose, right? Writing a space/tab instead of a "w". His goal was to compress more code into one line, which is horrible API design as has been pointed out a few times.
Further,
@w->setName();
w->setThis();
w->setThat();@
is much easier searchable, replaceable, regexable, reorderable and finally readable than your version, in my opinion.[quote]to make code look more shell-like.[/quote]
so... to make code feel less intuitive in order to give the feeling of using 40 year old unix CLI syntax? Noble goals... ;)
Just kidding, QEasyShell looks cool. And that's actually a good point to mention. This idiom of returning a this pointer to allow such lines of code with much information content is great for scripting languages, e.g. shell scripts. But C++ isn't a scripting language and programs tend to have more than 1 kloc. So while scripting languages can and should give the developer the freedom to pump out enormous functionality in shortest times, languages intended for large scale development should actually limit the developers in many respects, to make them think about their code and lay out the logic of the program very clearly. -
Hi, thank you very much to everybody for your interesting comments.
I know this was a very vague idea, but I'd like to point out that "weird" or "unreadable" code is much a subjective idea, and I think that an API itself is not responsible for how the code will be written, but it should better give users maximum freedom on how to work. For example, I personally find a code much more readable if I can read a whole functional block of code in a single screen without having to scroll.
Bye
Michele -
Actually Qt already uses such fluent interfaces in spots, like QString (<code>QString(...).remove(...).append(...)</code>) or QDataStream.
I see the benefits of having the possibility of method chaining, and this should be proposed for Qt6 (so it will be at least discussed).
RIM already provides a (or some kind of) fluent interface in a binary compatible way for their Cascades Framework (which is based on Qt) using their Builder concept (as for example in "Cascades::Sheet":https://developer.blackberry.com/cascades/reference/bb__cascades__sheet.html).
-
Yeah, but Qt6 is a long time away. Also, wouldn't that add a (minimal) performance penalty? And last but not least, judging by the declarative direction of Qt, there will hardly be anything to chain. With QML or any other markup being used to set properties in a declarative way, this whole endeavor seems (almost entirely) redundant.
-
Binary incompatible changes, as for instance changing the return value, aren't allowed within a major release. So this would have to go in Qt6 no matter what.
There is indeed a minuscle performance penalty, which is however irrelevant in practice compared to the work in a non-trivial setter.
Yes, this does not affect QtQuick, but this doesn't mean that QtWidgets couldn't or shouldn't be improved.
-
[quote author="utcenter" date="1360623465"]Honestly, I'd be surprised if widgets are still alive in Qt6 timeframe.[/quote]If that happens, I will personally fork Qt and invite everybody to continue with a Framework for proper applications. Everybody else may use QML for their thirty-thousandth flickable photo album app and tetris clone.
-
There is too much of a code base to support, so I doubt widgets will be removed altogether, but consider that Qt6 might very well be 5+ years away. It took almost 8 years from Qt4 to Qt5. Widgets will probably look as awkward as Qt3 widgets today.
Despite the current lack of initiative, I honestly expect that Qt5 will actually see a new, better, more flexible and lighter C++ API to substitute widgets, which are stiff and centered around a fixed UI paradigm that fits less and less into the world of today.
-
As someone that earns his bread doing Qt work, I can tell you that QtQuick is being used for 'real' applications. With good success too.
The thing that catches many by surprise is that the applications that used to be 'real' stopped being the main group of apps. I'm talking about those applications that people use in the office. From Word/Excel to hours-management apps. But also apps like used by stores, marketing etc etc.
Those serious apps are still there, but the rest of the apps are growing much faster due to availability of speciality hardware. And QML is perfectly suited for the majority of 'real' apps.Sorry for the incoherent explanation, I hope it may at least give one person a "oh, I understand" feeling ;)
