Proposal: useful return values instead of void

[m.alessandrini]

Hi, I don't know if it's the right group to make proposals about the API, but I think it would be useful to have some functions return something instead of void. For example, the various setXxxx() methods could return "this" instead of void.
Consider this example:
@
QLabel *l = new QLabel("...", this);
l->setBuddy(...);
l->setWordWrap(...)
... other set functions
layout->addWidget(l);
@
Now consider if every function returned a "this" pointer:
@
layout->addWidget((new QLabel("...", this))->setBuddy(...)->setWordWrap(...)->ecc ecc);
@
Much more compact, and no temporary variable.
As a general principle, this could apply to many other kind of functions too.

Bye and thanks for all
Michele Alessandrini

Edit: please use @ tags around code sections; Andre

[sierdzio]

Monads, monads everywhere :) I like this kind of "this" returning, but, as you rightly suspect, this is not the right place to propose API changes. You need to send this to "Development":http://lists.qt-project.org/mailman/listinfo/development mailing list.

What you are proposing, though, is too big a change to be included in any Qt5 release. I would have to wait (probably several years) for Qt6. And that only if you round up many people in your support. And best if you submit patches yourself, too :)

[m.alessandrini]

Hi, thank for your reply!
I did not suspect that there would exist BOTH forums and mailing lists :-) And "development" confused me because you are always a developer when using Qt :-)
I realize that's a big change, and maybe too vague, and maybe touching every single Qt source file! But actually in this case it would not be "noticed" by code calling the void-type functions, cause they already ignore the returned value.
Anyway, just launching some hints...
Bye
Michele

[utcenter]

Returning a reference to the instance after every method member call that doesn't need to return a useful value to allow chaining is not that bad of an idea.

Nonetheless I doubt this will be incorporated regardless of where you take your proposal.

[DerManu]

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.

[vidar]

I like the idea, it is more close to a "natural" language.
@DerManu: you can still use the old style even if "this" is returned. :)

[ChrisW67]

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-> ...;
@

[tzander]

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...

[GrahamL]

http://www4.in.tum.de/~blanchet/api-design.pdf

[JKSH]

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 :)

[sierdzio]

Qt slots are just standard c++ methods, they can return anything. Signals should be declared with void return.

[john_god]

Thanks for sharing the "The Little Manual of API Design" link.
I got a felling that I'm going to enjoy it reading very much. I was not aware of that manual.

Cheers

[andre]

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.

[sierdzio]

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).

[MianKashifAli]

There should always the concept of void, it sometimes relax a "new to programming person's" mind. Anyhow suggestion is great for experts.

[DerManu]

[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.

[m.alessandrini]

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

[lgeyer]

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).

[utcenter]

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.

[lgeyer]

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.