Re: OC method call in style of CPP rather than message sending
Luke Kendall <[email protected]> Mon, 6 Nov 2023 18:53:21 +1100
| Newsgroups | gmane.comp.lib.gnustep.applications |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============2990250486200614872== Content-Type: multipart/alternative; boundary="------------aPYAEnMw7sY798gURvCapL0u" Content-Language: en-GB This is a multi-part message in MIME format. --------------aPYAEnMw7sY798gURvCapL0u Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I agree with Daniel. Objective C was developed following Smalltalk, at a time when its method syntax was very influential in language design and the whole Object Oriented model of programming was a very new thing. I came to very much prefer the very distinctive syntax, since it made it very clear when you were using objects (and thus there could be extra layers of work being done by the compiler or runtime to handle the construct), and when you were using simple functional programming. Provided your code editor supported bracket checking, it was very easy to see and understand the nesting level. From memory IIRC our coding standard adopted the convention of breaking out the square brackets to vertically match if the line got very long. Personally I think having Smalltalk syntax and C syntax to demarcate the two kinds of code is clear, if a little unusual in a language design. Adding in a 3rd syntax from another language, especially one that straddles the two programming models (OO *and* functional) might allow some subtle mistakes to be made. Just my two cents. luke On 6/11/23 02:43, Daniel Boyd via apps-gnustep wrote: > I’m far from the being an authority on ObjC relative to others on this > listserv, but I’ll take a stab at responding. The reason ObjC has its > syntax is largely because it was developed around the same time as C++ > (slightly after, but close enough) — in other words, it was developed > at a time before the C++-style syntax had become a de facto standard. > ObjC’s syntax style was largely derived from Smalltalk. > > Personally, I like ObjC’s syntax. It was certainly a change from what > I was used to, but I actually prefer it in a lot of scenarios. The > time when I don’t like it is when you have a line that starts with > [[[[ and you have to really work to figure how many opening square > brackets you need. > > And regarding whether you can use C++-style syntax, to use ObjC—that’s > kind of a meaningless question. That syntax, for all intents and > purposes *is* Objective C. I think what you’re trying to ask is > whether you can do Cocoa programming using C++. Someone probably has > worked on that at some point, but I suspect it’s not well supported. > My suggestion is to try and learn Objective C and you may be surprised > to learn that you like it after you get used to it :) > > Cheers, > Daniel > > Sent from my iPhone > >> On Nov 5, 2023, at 09:13, loserism <[email protected]> wrote: >> >> >> >> Hi all. >> >> Is there a way for Objective-C to use C++ form of method calls? I.e. >> use obj.method(<args>) form of method call instead of [obj method: >> <args>]? >> >> obj.methodA(<args>).methodB(<args>)... .methodN(<args>) >> >> instead of >> >> [.... [obj methodA: <args>] methodB: <args>] methodC: <args>]...] >> methodN: <args>...] >> >> I mean that use the method invocation style instead of the message >> sending style. >> >> I'm curious as to why OC must use the message sending style to stand >> out instead of the more generic method calling style, I don't believe >> it's a technicality! >> >> >> By the way sorry, I came here to annoy you all because I couldn't >> find the relevant answers on google and GPT, because I know you are >> the most knowledgeable group of OC experts, and I hope to get a reply >> from you. Thank you all! >> >> >> Best Regards! >> > > _______________________________________________ > apps-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/apps-gnustep --------------aPYAEnMw7sY798gURvCapL0u Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix"> <p>I agree with Daniel.</p> </div> <div class="moz-cite-prefix"> <p>Objective C was developed following Smalltalk, at a time when its method syntax was very influential in language design and the whole Object Oriented model of programming was a very new thing.</p> </div> <div class="moz-cite-prefix"> <p>I came to very much prefer the very distinctive syntax, since it made it very clear when you were using objects (and thus there could be extra layers of work being done by the compiler or runtime to handle the construct), and when you were using simple functional programming.</p> </div> <div class="moz-cite-prefix"> <p>Provided your code editor supported bracket checking, it was very easy to see and understand the nesting level. From memory IIRC our coding standard adopted the convention of breaking out the square brackets to vertically match if the line got very long.</p> </div> <div class="moz-cite-prefix"> <p>Personally I think having Smalltalk syntax and C syntax to demarcate the two kinds of code is clear, if a little unusual in a language design.</p> </div> <div class="moz-cite-prefix"> <p>Adding in a 3rd syntax from another language, especially one that straddles the two programming models (OO *and* functional) might allow some subtle mistakes to be made.</p> <p>Just my two cents.<br> </p> </div> <div class="moz-cite-prefix"> <p>luke</p> </div> <div class="moz-cite-prefix"><br> </div> <div class="moz-cite-prefix">On 6/11/23 02:43, Daniel Boyd via apps-gnustep wrote:<br> </div> <blockquote type="cite" cite="mid:[email protected]"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div>I’m far from the being an authority on ObjC relative to others on this listserv, but I’ll take a stab at responding. The reason ObjC has its syntax is largely because it was developed around the same time as C++ (slightly after, but close enough) — in other words, it was developed at a time before the C++-style syntax had become a de facto standard. ObjC’s syntax style was largely derived from Smalltalk. </div> <div><br> </div> <div>Personally, I like ObjC’s syntax. It was certainly a change from what I was used to, but I actually prefer it in a lot of scenarios. The time when I don’t like it is when you have a line that starts with [[[[ and you have to really work to figure how many opening square brackets you need.<br> </div> <div><br> </div> <div>And regarding whether you can use C++-style syntax, to use ObjC—that’s kind of a meaningless question. That syntax, for all intents and purposes *is* Objective C. I think what you’re trying to ask is whether you can do Cocoa programming using C++. Someone probably has worked on that at some point, but I suspect it’s not well supported. My suggestion is to try and learn Objective C and you may be surprised to learn that you like it after you get used to it :)</div> <div><br> </div> <div>Cheers,</div> <div>Daniel</div> <div><br> </div> <div>Sent from my iPhone</div> <div dir="ltr"><br> <blockquote type="cite">On Nov 5, 2023, at 09:13, loserism <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:<br> <br> </blockquote> </div> <blockquote type="cite"> <div dir="ltr"> <p style="margin:0;">Hi all.</p> <p style="margin:0;">Is there a way for Objective-C to use C++ form of method calls? I.e. use obj.method(<args>) form of method call instead of [obj method: <args>]? </p> <table style=" border-collapse: collapse; table-layout: auto; font-size: inherit; border: 1px solid #D7D7D7; overflow: hidden;"> <tbody> <tr style="border: 1px solid #D7D7D7;"> <td colspan="1" rowspan="1" data-colwidth="527" style="border-right: 1px solid #D7D7D7; border-bottom: 1px solid #D7D7D7; padding: 3px 8px; height: 36px; word-break: break-all; overflow-wrap: break-word;"> <p style="margin:0;">obj.methodA(<args>).methodB(<args>)... .methodN(<args>) </p> </td> </tr> </tbody> </table> <p style="margin:0;"> </p> <p style="margin:0;">instead of</p> <table style=" border-collapse: collapse; table-layout: auto; font-size: inherit; border: 1px solid #D7D7D7; overflow: hidden;"> <tbody> <tr style="border: 1px solid #D7D7D7;"> <td colspan="1" rowspan="1" data-colwidth="770" style="border-right: 1px solid #D7D7D7; border-bottom: 1px solid #D7D7D7; padding: 3px 8px; height: 36px; word-break: break-all; overflow-wrap: break-word;"> <p style="margin:0;">[.... [obj methodA: <args>] methodB: <args>] methodC: <args>]...] methodN: <args>...]</p> </td> </tr> </tbody> </table> <p style="margin:0;">I mean that use the method invocation style instead of the message sending style.</p> <p style="margin:0;">I'm curious as to why OC must use the message sending style to stand out instead of the more generic method calling style, I don't believe it's a technicality!</p> <p style="margin:0;"><br> </p> <p style="margin:0;">By the way sorry, I came here to annoy you all because I couldn't find the relevant answers on google and GPT, because I know you are the most knowledgeable group of OC experts, and I hope to get a reply from you. Thank you all!</p> <p style="margin:0;"><br> </p> <p style="margin:0;">Best Regards!</p> </div> </blockquote> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ apps-gnustep mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.gnu.org/mailman/listinfo/apps-gnustep">https://lists.gnu.org/mailman/listinfo/apps-gnustep</a> </pre> </blockquote> <p><br> </p> </body> </html> --------------aPYAEnMw7sY798gURvCapL0u-- --===============2990250486200614872== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYXBwcy1nbnVz dGVwIG1haWxpbmcgbGlzdAphcHBzLWdudXN0ZXBAZ251Lm9yZwpodHRwczovL2xpc3RzLmdudS5v cmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWdudXN0ZXAK --===============2990250486200614872==--