tag:blogger.com,1999:blog-8397311766319215218.post1848955363786684625..comments2023-11-29T18:05:17.337+01:00Comments on metablog: Cargo-cult typing, or: Objective-C's default type is idMarcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-8397311766319215218.post-63445325140120460002017-11-08T23:23:55.902+01:002017-11-08T23:23:55.902+01:00You link to Occam's Razor as a justification f...You link to Occam's Razor as a justification for omitting the return value, but that's not at all what ol' Billy meant by it. He simply meant that, all else being equal, the mechanism of an observation with the fewest implicit assumptions is usually the correct one. It was never intended to suggest that one should prefer to write something with the fewest number of symbols. It never had anything to do with syntax.<br /><br />You could write your blog post without any articles ("the", "a", etc), and it would use fewer symbols and convey equivalent meaning, but I don't think anyone would claim this would make it easier to read, or that Occam's Razor says you should do this.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-1729033778683686242016-07-05T21:48:33.872+02:002016-07-05T21:48:33.872+02:00@Anonymous:
Nice analogy, but wrong. In Objectiv...@Anonymous:<br /><br />Nice analogy, but wrong. In Objective-C, "I return nothing" is not "nothing", but the (void) return type, whereas saying nothing means you return an id. Furthermore, it is hard to confuse the two, because the compiler will yell at you if you claim that you return something and then don't.Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-30996630446080055692016-06-08T03:23:49.094+02:002016-06-08T03:23:49.094+02:00"the ritual is empty, because it conveys no i..."the ritual is empty, because it conveys no information to the type system, or the reader"<br /><br />It does to me: it tells me that you are intentionally returning an object.<br /><br />Suppose my wife tells me to pick up my son Kyle on the way home. I text her either (a) nothing, (b) "on my way home", (c) "have kid, on my way home", (d) "have Kyle, on my way home". Each of these conveys different information.<br /><br />Even though the people in my car are exactly the same, in case (a) or (b), maybe she's not 100% sure if it's because everything's right, or I just forgot. In case (c), it's clear that I remembered, and while it's not explicit the identity of the kid in my car, it's pretty unlikely that I have the wrong one.<br /><br />These cases, of course, correspond to no type, (id), (instancetype), and (MyTypeName).<br /><br />I know people who, if I did (b) in real life, would say "Of course -- don't bother texting me if everything is fine". I know people who expect (d) in all situations, and otherwise assume the worst. Personally I think (b) or (c) are most reasonable, as they suggests that I'm on top of things, without being overly explicit in every detail.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-86180989380334386092016-04-29T23:32:49.133+02:002016-04-29T23:32:49.133+02:00I was inspired by your post, especially the histor...I was inspired by your post, especially the historical part about omitting id type, which is one of the weirdest things in Objective C for a modern developer. I'm linking to this post from an article about the <a href="http://dobegin.com/objc-id-type/" rel="nofollow">Objective C id data type</a>. Thank you.<br />battlmonstrhttps://www.blogger.com/profile/16702815228419690927noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-55381300681233641822014-03-10T10:35:54.437+01:002014-03-10T10:35:54.437+01:00I would suggest to make the "return nil"...I would suggest to make the "return nil" a guard clause:<br /><br />if (anIndex >= [self count]) {<br /> return nil;<br />}<br />return objects[anIndex];<br /><br />Or if you don't measure line coverage:<br /><br />if (anIndex >= [self count]) return nil;<br /><br />return objects[anIndex];Tammo Freesenoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-13159728102401895002014-03-06T08:11:48.638+01:002014-03-06T08:11:48.638+01:00@emp: That's very cool, I'll have to chec...@emp: That's very cool, I'll have to check it out.<br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-39634758461317751762014-03-06T03:47:02.019+01:002014-03-06T03:47:02.019+01:00"the code certainly doesn't become more r..."the code certainly doesn't become more readable"<br /><br />I don't agree. It may be syntactic 'noise', but it serves to make the semantics more clear to the human programmer.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-47160530518135539512014-03-05T22:37:12.616+01:002014-03-05T22:37:12.616+01:00I've tried to make Objective-C as Smalltalk an...I've tried to make Objective-C as Smalltalk an experience as possible, namely live coding and restarting an app only when the changes to the app state are not easily patched in the IDE.<br /><br />My favourite setup is to use http://injectionforxcode.com for hot code reloading.<br />Reloading hot code however breaks the IDE breakpoints.<br /><br />But for a nice Squeak/Pharo <i>self halt.</i> experience, you can <i>raise(SIGABRT);</i> which will break execution nicely, albeit a stack frame or two away.<br /><br />Along with a nice IDE like AppCode, I don't miss Smalltalk as much as I did before.empnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-22132069649350053042014-03-05T22:32:52.614+01:002014-03-05T22:32:52.614+01:00@Marcin:
I haven't really come to a conclusio...@Marcin:<br /><br />I haven't really come to a conclusion regarding (instancetype). On the one hand, it actually makes some sense, unlike (id), because it conveys additional information that we actually couldn't reasonably express before. So I kind of like the fact that is there.<br /><br />In terms of actually helping the user, I am not sure whether the information outweighs the clutter, since it is typically used in highly idiomatic situations where that information is really already known.<br /><br />I think I should stress that in both cases, instancetype and id, I don't think it makes a huge difference which way you choose. I've certainly been reading over the (id) returns for many years without noticing them much. In fact, I was surprised how far back the convention to put the redundant (id) goes (NeXTStep 3.x, as far as I can tell). Actually adding them, though, is a bit painful though (parsimony).<br /><br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-35289101723279793462014-03-05T22:32:06.213+01:002014-03-05T22:32:06.213+01:00"the code certainly doesn't become more r..."the code certainly doesn't become more readable"<br /><br />I disagree. But then, I've only been programming in Objective-C for 10 or 12 years (not as long as several other languages I know), so I grant that it might get easier with time. :-)<br /><br />There's a whole continuum of "explicitly declare nothing" to "explicitly declare everything". It's not terribly helpful to plant a flag in the ground and declare that it is the Right Place for that line, for 'readability', for all programmers.<br /><br />I like to think we have a slightly higher standard for docs today than 'early NeXTStep docs'! But it would also be a straightforward thing to test. You could grab NSArray.h and NSArray.html, and make copies with all the (id)'s removed, and do a survey. You could even ask new/intermediate/experienced Objective-C programmers separately, to find out if the preference changes with time. I would love to see that, especially if it showed that I'm in the minority here.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-50149957184641864982014-03-05T21:46:58.921+01:002014-03-05T21:46:58.921+01:00Could you please elaborate a little more on having...Could you please elaborate a little more on having <i>instancetype</i> as return type in the light of arguments you made?Marcinnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-42178330280855537672014-03-05T20:18:59.539+01:002014-03-05T20:18:59.539+01:00@Anonymous: Thanks for your comment, but what yo...@Anonymous: Thanks for your comment, but what you write is actually not true. <i>Not</i> having an explicit return type conveys that the method returns something (an object), whereas the fact that nothing is returned is indicated by the explicit return type "void".<br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-45985030578083193682014-03-05T20:08:25.303+01:002014-03-05T20:08:25.303+01:00Having a return type conveys that the method retur...Having a return type conveys that the method returns something. That was easy.Anonymousnoreply@blogger.com