Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Proposal: useful return values instead of void
Forum Updated to NodeBB v4.3 + New Features

Proposal: useful return values instead of void

Scheduled Pinned Locked Moved General and Desktop
26 Posts 14 Posters 7.0k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    sierdzio
    Moderators
    wrote on 7 Feb 2013, 16:37 last edited by
    #2

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

    (Z(:^

    1 Reply Last reply
    0
    • M Offline
      M Offline
      m.alessandrini
      wrote on 7 Feb 2013, 20:07 last edited by
      #3

      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

      1 Reply Last reply
      0
      • U Offline
        U Offline
        utcenter
        wrote on 7 Feb 2013, 20:08 last edited by
        #4

        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.

        1 Reply Last reply
        0
        • D Offline
          D Offline
          DerManu
          wrote on 7 Feb 2013, 23:45 last edited by
          #5

          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.

          1 Reply Last reply
          0
          • V Offline
            V Offline
            vidar
            wrote on 8 Feb 2013, 06:19 last edited by
            #6

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

            1 Reply Last reply
            0
            • C Offline
              C Offline
              ChrisW67
              wrote on 8 Feb 2013, 06:51 last edited by
              #7

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

              1 Reply Last reply
              0
              • T Offline
                T Offline
                tzander
                wrote on 8 Feb 2013, 06:52 last edited by
                #8

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

                1 Reply Last reply
                0
                • G Offline
                  G Offline
                  GrahamL
                  wrote on 8 Feb 2013, 07:48 last edited by
                  #9

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

                  1 Reply Last reply
                  0
                  • J Offline
                    J Offline
                    JKSH
                    Moderators
                    wrote on 8 Feb 2013, 08:08 last edited by
                    #10

                    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 Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                    1 Reply Last reply
                    0
                    • S Offline
                      S Offline
                      sierdzio
                      Moderators
                      wrote on 8 Feb 2013, 08:12 last edited by
                      #11

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

                      (Z(:^

                      1 Reply Last reply
                      0
                      • J Offline
                        J Offline
                        john_god
                        wrote on 8 Feb 2013, 09:34 last edited by
                        #12

                        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

                        1 Reply Last reply
                        0
                        • A Offline
                          A Offline
                          andre
                          wrote on 8 Feb 2013, 10:11 last edited by
                          #13

                          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.

                          1 Reply Last reply
                          0
                          • S Offline
                            S Offline
                            sierdzio
                            Moderators
                            wrote on 8 Feb 2013, 10:16 last edited by
                            #14

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

                            (Z(:^

                            1 Reply Last reply
                            0
                            • M Offline
                              M Offline
                              MianKashifAli
                              wrote on 8 Feb 2013, 10:27 last edited by
                              #15

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

                              1 Reply Last reply
                              0
                              • D Offline
                                D Offline
                                DerManu
                                wrote on 8 Feb 2013, 10:55 last edited by
                                #16

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

                                1 Reply Last reply
                                0
                                • M Offline
                                  M Offline
                                  m.alessandrini
                                  wrote on 11 Feb 2013, 08:08 last edited by
                                  #17

                                  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

                                  1 Reply Last reply
                                  0
                                  • L Offline
                                    L Offline
                                    lgeyer
                                    wrote on 11 Feb 2013, 11:21 last edited by
                                    #18

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

                                    1 Reply Last reply
                                    0
                                    • U Offline
                                      U Offline
                                      utcenter
                                      wrote on 11 Feb 2013, 11:30 last edited by
                                      #19

                                      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.

                                      1 Reply Last reply
                                      0
                                      • L Offline
                                        L Offline
                                        lgeyer
                                        wrote on 11 Feb 2013, 14:33 last edited by
                                        #20

                                        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.

                                        1 Reply Last reply
                                        0
                                        • U Offline
                                          U Offline
                                          utcenter
                                          wrote on 11 Feb 2013, 22:57 last edited by
                                          #21

                                          Honestly, I'd be surprised if widgets are still alive in Qt6 timeframe. Maybe in some form similar to the Qt3 compatibility module in Qt4.

                                          1 Reply Last reply
                                          0

                                          11/26

                                          8 Feb 2013, 08:12

                                          • Login

                                          • Login or register to search.
                                          11 out of 26
                                          • First post
                                            11/26
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved