Proposal: useful return values instead of void
-
-
I don't really see the benefits here. Sure you can cram up more information in a single line, but when (since program memory isn't an issue anymore) has this ever been a good idea? Code should be untangled and laid out clearly, not compressed. If you want to compress, C++ gives you all the power, just write
w->setName();w->setThis();w->setThat();
and enjoy perl-like unreadability. -
If the functions return a pointer you get this mixed syntax when using a stack based object:
@
Object w;
w.doStuff()->doMoreStuff()-> ...;
@and if the function returns a reference you get this mixed syntax when using heap objects:
@
Object *w;
w->doStuff().doMoreStuff(). ...;
@Personally I think I prefer the consistency and clarity of:
@
Object w;
w.doStuff();
w.doMoreStuff()
w. ...;
// or
Object *w;
w->doStuff();
w->doMoreStuff()
w-> ...;
@ -
There is a nice document that came out of research Trolltech did back when they made Qt.
The research is about how to write useful APIs.
One of the main things is "code will be read more often then it is written, so write for readability".
I think this suggestion would make code much less readable, it would be easy to miss that one 'set' being doing on a long line of setters.
The book is "The Little Manual of API design". You might find it floating around the internernet somewhere since the original location seems to have gone blank... -
-
Qt slots need to return void, no? QLabel::setText() is a slot, so it can't be made to return `this' (unless slot requires are changed in the future)
[quote author="m.alessandrini" date="1360267667"]But actually in this case it would not be "noticed" by code calling the void-type functions, cause they already ignore the returned value.[/quote]True, the change is source-compatible. But, it's not binary-compatible (http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ ), so the change can't be done in Qt 5.
Nonetheless, thanks for sharing your suggestion! If you're passionate about this issue, bring up the discussion again when Qt 6 is approaching, and we'll see where we stand then :)
-
Qt slots are just standard c++ methods, they can return anything. Signals should be declared with void return.
-
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.
