Re: Looking at self = [super init].
On Jun 3, 2015, at 8:02 AM, Alex Zavatone z...@mac.com wrote: On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: On Jun 1, 2015, at 11:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Although I have the luxury of requiring modern runtime capable systems, some people do still have to target the old runtime… ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I think. Also, FWIW the modern runtime only handles same-named instance variables that are privately declared; same-named variables declared in an @interface section will conflict even on the modern runtime. Variables declared in an @interface section trigger a compiler warning: warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars] Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable. OK. This is very important to me. Where in the project can I set these flags so that they are project wide (or remove these flags) so that we get those warnings. Project Target Build Settings - But under which section? I have a metric crapload of these to sort out as time permits and would LOVE to turn on these warning flags so I can bring this part of project up to 2012 standards, and then maybe eventually to 2015 standards. But one step at a time. What I do is to put -Weverything in “Other Warning Flags”. Then, I add -Wno flags for all the ones I want to turn off (and trust me, there’ll be a bunch of those). Then, at the end, you have a string that you can just copy and paste into your new projects and get the warnings set up exactly how you like them, and you’ll get new warnings as soon as they’re added to Clang. There is one hitch here, which is that you have to make sure there aren’t any flags set to “No” in the build settings for Warnings, because each one of those adds a -Wno of its own to the build command. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 3, 2015, at 9:02 AM, Alex Zavatone wrote: On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: On Jun 1, 2015, at 11:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Variables declared in an @interface section trigger a compiler warning: warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars] Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable. OK. This is very important to me. Where in the project can I set these flags so that they are project wide (or remove these flags) so that we get those warnings. Project Target Build Settings - But under which section? I have a metric crapload of these to sort out as time permits and would LOVE to turn on these warning flags so I can bring this part of project up to 2012 standards, and then maybe eventually to 2015 standards. AHA! I couldn't find out how to add it through the Build Settings, (thanks terrible UI!), but If you want this in your project and your project has a .pch file, you can turn on the warning through a pragma and a clang diagnostic push by adding the code below to your .project wide header file. / AZ @@ 06030215 - Enable warnings on build for private interface variables manually declared in the @interface. # pragma clang diagnostic push # pragma clang diagnostic warning -Wobjc-interface-ivars Thanks to Matt Thompson for his pragma article and the Clang docs. http://nshipster.com/pragma/ http://clang.llvm.org/docs/UsersManual.html http://fuckingclangwarnings.com/ Hope this is of use to some of you too. Cheers, Alex Zavatone ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 3, 2015, at 6:30 AM, Alex Zavatone z...@mac.com wrote: With that in mind, what should it have depended on instead? His point was not that such dependence was bad, nor even avoidable. His point was that the C++ was a steaming pile ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 9:07 PM, Michael David Crawford wrote: What horrified me was that they were completely unaware that their product was likely to drop a pickup truck on top of an assembly plant worker. While the overall architecture had all manner of fault-tolerance engineered in, that fault-tolerance depended on correct C++ code. With that in mind, what should it have depended on instead? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 3:13 PM, Charles Srstka wrote: On Jun 1, 2015, at 11:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Although I have the luxury of requiring modern runtime capable systems, some people do still have to target the old runtime… ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I think. Also, FWIW the modern runtime only handles same-named instance variables that are privately declared; same-named variables declared in an @interface section will conflict even on the modern runtime. Variables declared in an @interface section trigger a compiler warning: warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars] Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable. OK. This is very important to me. Where in the project can I set these flags so that they are project wide (or remove these flags) so that we get those warnings. Project Target Build Settings - But under which section? I have a metric crapload of these to sort out as time permits and would LOVE to turn on these warning flags so I can bring this part of project up to 2012 standards, and then maybe eventually to 2015 standards. But one step at a time. That doesn’t help if I’m looking at some code that someone else wrote, or code that I wrote 5 years ago, noticing a variable name being used somewhere, and having to hunt around for the declaration to figure out whether it’s a local variable, an instance variable, or something stupid like a global or something. This is the exact issue that I have in my project where some ivars are declared in the @interface with the same name as the @property. Sadly, within Xcode, there is no easy convention (like color coding the difference between the two) to show the difference between the an ivar and an @property with the same name within the class files. On Jun 1, 2015, at 3:14 PM, Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: Non-underscored ivars vs. local variables, however, are not obvious at all, especially if the method is large. Yeah, I think I mentioned this last week and it is the cause of great pain in my current project. Especially when you have 4 thousand line view controllers that include other view controllers and have a delegate that is an other view controller. In modern versions of Xcode at least, if I don’t know exactly what I’m looking at, the answer is just a command-click away… :-) Sadly, in my situation, that generally only gets me 1/4 of the way there. That can be handy, when it works. Sometimes it doesn’t (particularly when you’re using Swift, in which command-click usually just brings up an endless circular progress indicator). Also, the syntax highlighting does render (at least on my setup) in different colors for local variables and instance variables. That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help. That may be nice, but there is still NO DIFFERENCE AT ALL between the colors for instance variables and properties (or way to set them) within Xcode. Unless there's something I missed. Can we add our own coloring rules? Really glad we're touching in these topics. These are me helping wrangle my project immensely. Best, Alex Zavatone ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 9:53 PM, Scott Ribe scott_r...@elevated-dev.com wrote: On Jun 1, 2015, at 10:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: So…. it looks like clang at least is doing the right thing and calling the destructor when the variable goes out of scope. Yep. But I believe with goto you can skip over a constructor--but at least you get a warning. I just tried… I get an error, not a warning: “Goto into protected scope”. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 11:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: Although I have the luxury of requiring modern runtime capable systems, some people do still have to target the old runtime… ARC requires the modern runtime, which has pretty much caused the old one to drop off the map for most people, I think. Also, FWIW the modern runtime only handles same-named instance variables that are privately declared; same-named variables declared in an @interface section will conflict even on the modern runtime. Variables declared in an @interface section trigger a compiler warning: warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars] Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable. That doesn’t help if I’m looking at some code that someone else wrote, or code that I wrote 5 years ago, noticing a variable name being used somewhere, and having to hunt around for the declaration to figure out whether it’s a local variable, an instance variable, or something stupid like a global or something. On Jun 1, 2015, at 3:14 PM, Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: Non-underscored ivars vs. local variables, however, are not obvious at all, especially if the method is large. In modern versions of Xcode at least, if I don’t know exactly what I’m looking at, the answer is just a command-click away… :-) That can be handy, when it works. Sometimes it doesn’t (particularly when you’re using Swift, in which command-click usually just brings up an endless circular progress indicator). Also, the syntax highlighting does render (at least on my setup) in different colors for local variables and instance variables. That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 12:13 PM, Charles Srstka cocoa...@charlessoft.com wrote: That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help. It depends on what the colors are. Almost no one is entirely colorblind; usually it’s just red and green that are problematic. But yes, you might be a dog, with no color vision at all. In that case you can configure syntax ‘coloring’ to use different text styles or even different fonts. So you could highlight ivars with italics or underlines or a serif font or something. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 2 Jun 2015, at 11:02, Jeremy Pereira jeremy.j.pere...@googlemail.com
wrote:
On 1 Jun 2015, at 19:11, Dave d...@looktowindward.com wrote:
Exactly, so make it more readable, to me anyway, unnecessary braces just add
to complexity or at least makes the method look more complex than it
actually is.
N!
Complexity is not about how many braces there are and how much indentation
there is. Complexity is about the number of different execution paths and
states.
I said it makes it “look” more complex, not that it made it more complex, which
may or not be the same thing.
There is also the problem of maintainability. What if you want to add a line
of code?
If you want to add it before the execution of lots of code, no problem in
either case. If you want to add it after the execution of lots of code,
again no problem if you only want to execute it only if foo is true.
Well Obviously then you do:
if (X == YES)
{
}
else
{
}
As far as maintainability is concerned, I find less braces more maintainable.
There are always cases when you can’t do an early return, in those cases of
course you need to add braces, but if possible I always use an early return.
Cheers
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 1:28 PM, Charles Srstka cocoa...@charlessoft.com wrote: Dogs don’t completely lack color vision. Also, calling a person a dog could really come across in a way that you’re not intending. Sorry, not intended! I was thinking more of “On cocoa-dev, no one knows you’re a dog”. Anyway, yes, one could ugly up one’s code with italics and boldface and whatnot, but simply prefixing the ivar name with an underscore is simpler, it prevents accidentally referencing the ivar and/or shadowing it with a local variable, and it’s what Apple recommends. Better all around, if you ask me. I agree, actually. But in Swift the concept of ivar no longer exists, so I have to rely on color/style to distinguish properties from locals. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 3:31 PM, Jens Alfke j...@mooseyard.com wrote: Anyway, yes, one could ugly up one’s code with italics and boldface and whatnot, but simply prefixing the ivar name with an underscore is simpler, it prevents accidentally referencing the ivar and/or shadowing it with a local variable, and it’s what Apple recommends. Better all around, if you ask me. I agree, actually. But in Swift the concept of ivar no longer exists, so I have to rely on color/style to distinguish properties from locals. My solution with Swift is to consistently use the “self.” prefix when referencing properties. If Apple could include an optional compiler warning to enforce this like they do with Obj-C auto-synthesis, it’d be *great* (hint hint for any Apple engineers that happen to be reading this). Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Jens, I don't see a setting in the Source Editor's Fonts and Colors that displays a difference between a class's properties and a class's ivars. When you apply a color change or a font change there is no visual differentiation between those two. Honestly, I would love to see the properties on one style and the ivars in another, but in the midnight scheme they take the same formatting. Sent from my iPod Touch. Please pardon typos. On Jun 2, 2015, at 3:41 PM, Jens Alfke j...@mooseyard.com wrote: On Jun 2, 2015, at 12:13 PM, Charles Srstka cocoa...@charlessoft.com wrote: That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help. It depends on what the colors are. Almost no one is entirely colorblind; usually it’s just red and green that are problematic. But yes, you might be a dog, with no color vision at all. In that case you can configure syntax ‘coloring’ to use different text styles or even different fonts. So you could highlight ivars with italics or underlines or a serif font or something. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 2:41 PM, Jens Alfke j...@mooseyard.com wrote: On Jun 2, 2015, at 12:13 PM, Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: That can be handy, if you’re not colorblind. If you are, the coloring isn’t much help. It depends on what the colors are. Almost no one is entirely colorblind; usually it’s just red and green that are problematic. And since red and green are two out of the three cones in your eyes, that leaves blue, and shades of it, as the only really easily distinguishable color. I can tell blue from red or green pretty easily. Red from green is a problem. Blue from purple is a problem. Green from brown is a problem. There are many other color combos that can also be mistaken from each other. It’s easiest just not to rely on colors. I can tell red and green apart, of course, if they’re right next to each other for contrast, like Yosemite’s window buttons, and if there’s a sufficiently large patch of the color (it was easier with the larger Snow Leopard-style buttons, but still possible with Lion/Yosemite). If you just showed me one of the window close buttons by itself, I would have trouble telling you whether it was red or green. With the skinny little lines that make up text (or line graphs, which I really hate), it’s next to impossible to tell the colors apart without using Digital ColorMeter, even if they’re right next to each other. But yes, you might be a dog, with no color vision at all. In that case you can configure syntax ‘coloring’ to use different text styles or even different fonts. So you could highlight ivars with italics or underlines or a serif font or something. Dogs don’t completely lack color vision. Also, calling a person a dog could really come across in a way that you’re not intending. Anyway, yes, one could ugly up one’s code with italics and boldface and whatnot, but simply prefixing the ivar name with an underscore is simpler, it prevents accidentally referencing the ivar and/or shadowing it with a local variable, and it’s what Apple recommends. Better all around, if you ask me. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
I once worked for a company that had quite meticulous style rules regarding comments. I was also required to use a specific text editor because someone had written scripts that either enabled or enforced the comment style rules. I resigned in protest because their actual source code is quite likely to get someone killed someday, quite likely a great many people. They do industrial control systems software. Consider that the Stuxnet and Flame worms attacked HMI/SCADA software. I do comment tricky stuff. While I don't write actual comments regarding input parameters or return results, I do assert them - assert( ptr != NULL ). I regard assertions as documentation not just tests; if you intentionally change the input parameter space, then your assertions will fail. Given that you really did want to change the parameters, you'll be forced to update the assertions as well. That's better than trying to keep comments in sync as there is no really satisfying test for correct comments. I quite commonly ask potential employers whether they have any kind of coding conventions. Whether I pursue the job has a lot to do with what those conventions actually are. If they're picky about their comments I withdraw my application. If their coding conventions are the sort that are likely to lead to correct code then I pursue the job with enthusiasm. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Tue, Jun 2, 2015 at 5:08 PM, Graham Cox graham@bigpond.com wrote: On 3 Jun 2015, at 9:03 am, Michael David Crawford mdcrawf...@gmail.com wrote: That's because comments are rarely maintained in sync with the actual source code. So part of the responsibility of coding well is to maintain comments, not to remove them altogether. At a minimum, I comment what a method does, in broad terms, and what the parameters are for, if they're not obvious. Also, any tricks should be commented. Any code that only works because of some hidden factor that isn't obvious should be commented. Any non-obvious algorithm should be commented, and so on. Code that is obvious is generally not worth commenting - it only adds clutter. The example you gave was obvious in my opinion, so there wouldn't normally be a comment there, even if it was correct. All this is usually covered in the style guide for coding that your employer probably has, if they do any sort of serious coding. If you work for yourself, you should have one as well. I don't trust completely uncommented code. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 3 Jun 2015, at 9:03 am, Michael David Crawford mdcrawf...@gmail.com wrote: That's because comments are rarely maintained in sync with the actual source code. So part of the responsibility of coding well is to maintain comments, not to remove them altogether. At a minimum, I comment what a method does, in broad terms, and what the parameters are for, if they’re not obvious. Also, any ”tricks” should be commented. Any code that only works because of some hidden factor that isn’t obvious should be commented. Any non-obvious algorithm should be commented, and so on. Code that is “obvious” is generally not worth commenting - it only adds clutter. The example you gave was “obvious” in my opinion, so there wouldn’t normally be a comment there, even if it was correct. All this is usually covered in the style guide for coding that your employer probably has, if they do any sort of serious coding. If you work for yourself, you should have one as well. I don’t trust completely uncommented code. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
While there were numerous reasons for my protest resignation, the reason I walked out - no notice given - was that I was the only one in the company who was aware that there even was such a thing as a C++ Smart Pointer. I knew something was up when I was told to stop referring to the computer programmers as the engineers. In Canada, it's a civil offense to call yourself an engineer unless you're the Canadian equivalent of an American Professional Engineer. At that company, the engineers was taken to mean the industrial control system engineers - those who worked with electrical and mechanical gadgets. All the software was written by computer programmers for no reason I can fathom. In mechanical drawing - more commonly known as drafting - there is always a very specific convention for documentation blocks in your drawing. There will be the company name, maybe a logo, the draftsman's name, revision numbers, a title, date and so on. I expect their comment fetish evolved from that. What horrified me was that they were completely unaware that their product was likely to drop a pickup truck on top of an assembly plant worker. While the overall architecture had all manner of fault-tolerance engineered in, that fault-tolerance depended on correct C++ code. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Tue, Jun 2, 2015 at 5:38 PM, Graham Cox graham@bigpond.com wrote: On 3 Jun 2015, at 10:19 am, Michael David Crawford mdcrawf...@gmail.com wrote: If their coding conventions are the sort that are likely to lead to correct code The reason for coding style guidelines is a) correctness b) maintainability. If it's just a fetish that the chief developer has and he can't back it up with reasoned argument then that's suspect. Having been handed several uncommented and undocumented messes and left to sort it out a couple of times in my career I'm very sensitive to the needs of developers coming to a codebase cold. I try to write code in such a way that I imagine a developer who's never seen it before could get up to speed in a relatively short time, even if 99% of the time that developer is me, several years removed. There's nothing worse than wasting hours wondering what the hell was I thinking? instead of just reading a comment that explains what I was thinking. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 3 Jun 2015, at 10:19 am, Michael David Crawford mdcrawf...@gmail.com wrote: If their coding conventions are the sort that are likely to lead to correct code The reason for coding style guidelines is a) correctness b) maintainability. If it’s just a fetish that the chief developer has and he can’t back it up with reasoned argument then that’s suspect. Having been handed several uncommented and undocumented messes and left to sort it out a couple of times in my career I’m very sensitive to the needs of developers coming to a codebase cold. I try to write code in such a way that I imagine a developer who’s never seen it before could get up to speed in a relatively short time, even if 99% of the time that developer is me, several years removed. There’s nothing worse than wasting hours wondering “what the hell was I thinking?” instead of just reading a comment that explains what I was thinking. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Tue, Jun 2, 2015, at 03:42 PM, Charles Srstka wrote: On Jun 2, 2015, at 3:31 PM, Jens Alfke j...@mooseyard.com wrote: I agree, actually. But in Swift the concept of ivar no longer exists, so I have to rely on color/style to distinguish properties from locals. My solution with Swift is to consistently use the “self.” prefix when referencing properties. If Apple could include an optional compiler warning to enforce this like they do with Obj-C auto-synthesis, it’d be *great* (hint hint for any Apple engineers that happen to be reading this). If you think this would be a worthwhile change to Swift, please file a Radar. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
After I pointed out my diligent use of comments to Scott Lydiard,
President of aerial photography firm Verde Technologies, he advised me
not comment my code in any way.
WUT?
That's because comments are rarely maintained in sync with the actual
source code.
For example:
int offset( void )
{
return 3; // return 4
}
This isn't the same as the jerks who think you're stupid if you can't
follow their logic. I regard it as my responsibility to make my
source clear and easy to maintain, even without comments.
However I am dead certain that it loses me work, when potential
clients look over my source and don't find any comments in it.
Mike
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Tue, Jun 2, 2015 at 2:22 PM, Kyle Sluder k...@ksluder.com wrote:
On Tue, Jun 2, 2015, at 03:42 PM, Charles Srstka wrote:
On Jun 2, 2015, at 3:31 PM, Jens Alfke j...@mooseyard.com wrote:
I agree, actually. But in Swift the concept of ivar no longer exists, so I
have to rely on color/style to distinguish properties from locals.
My solution with Swift is to consistently use the self. prefix when
referencing properties. If Apple could include an optional compiler
warning to enforce this like they do with Obj-C auto-synthesis, it'd be
*great* (hint hint for any Apple engineers that happen to be reading
this).
If you think this would be a worthwhile change to Swift, please file a
Radar.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 2, 2015, at 12:13 PM, Charles Srstka cocoa...@charlessoft.com wrote: Variables declared in an @interface section trigger a compiler warning: warning: declaration of instance variables in the interface is deprecated [-Wobjc-interface-ivars] Hmm… I’ve never seen that warning actually be emitted by clang… so, thinking something was amiss, I just created a brand new project file (Cocoa app; Objective-C; not document based) with Xcode Version 6.3.2 (6D2105); and went looking for where to turn that on/off in the target build settings… and I can’t find it. So, I then proceeded to add an int foo; declaration to the @interface of the app delegate — no warning emitted. In order to get it to show up I had to add it to the “Other C Flags” line under “Apple LLVM 6.1 - Custom Compiler Flags”. Oh, and there’s a nifty warning that’s thrown as soon as you try to declare a local variable of the same name as an instance variable. That doesn’t help if I’m looking at some code that someone else wrote, or code that I wrote 5 years ago, noticing a variable name being used somewhere, and having to hunt around for the declaration to figure out whether it’s a local variable, an instance variable, or something stupid like a global or something. Um… why does it matter? If you go to add a variable declaration and you immediately get a warning… just pick a different name? Or use the symbol navigator to find it (it’s got a search box) ? Or remove the type from the declaration (so that it’s now just a symbol reference) and command-click it? On Jun 1, 2015, at 3:14 PM, Charles Srstka cocoa...@charlessoft.com wrote: Non-underscored ivars vs. local variables, however, are not obvious at all, especially if the method is large. In modern versions of Xcode at least, if I don’t know exactly what I’m looking at, the answer is just a command-click away… :-) That can be handy, when it works. Sometimes it doesn’t (particularly when you’re using Swift, in which command-click usually just brings up an endless circular progress indicator). I’m not using Swift; and probably won’t be any time soon; so I can’t speak to Xcode’s current stability with Swift code. However, in Objective-C I rarely have a problem; and when I do performing a clean-and-build cycle has made it go away. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 2 Jun 2015, at 2:51 pm, Michael David Crawford mdcrawf...@gmail.com wrote: I've done that for decades but I've never seen anyone else do it. I do. Anyone who’s used any of my public Cocoa code will know this. I even like to lay out methods and properties in columns - almost everyone doesn’t so I don’t know how that goes down, but my headers are a lot more readable than most. I have been criticised for my coding style in the past because it “wastes space”, but I have far fewer problems coming back to code months or years later and seeing what’s what, because everything is clearly laid out. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for organization,
but if you're passing objects into into your init method, then you're passing
more data again and the code could get less cleaner looking than it could be.
So, I thought, why don't we check if self != [super init] and then
immediately return if that is the case?”
Totally agree, I always do it like this:
-(instanceType) init
{
self = [super init];
if (self == nil)
return nil;
// Init code here
return self;
}
I nearly prefer a fast return over using a Brace, for instance:
-(BOOL) someMethodWithParameter1:(NSString*) theParam1 andParam2:(NSString*)
theParam2
{
if (theParam1 == nil)
return NO;
if (theParam2 == nil)
return NO;
// Other code here
return YES;
}
In preference to:
-(BOOL) someMethodWithParameter1:(NSString*) theParam1 andParam2:(NSString*)
theParam2
{if (theParam1 != nil)
{
if (theParam2 != nil)
{
// Other code here
}
return YES;
}
return NO;
}
All the Best
Dave
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
RE: Looking at self = [super init].
The == case that has been mentioned just omits the second step because self
isn't modified by calling [super init]. And the equivalent statements for the
other case (! / ==) do the same thing except that the test step is the
inverse.
init is allowed to return a different self, so if you skip the assignment
you're looking at a stale self.
From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com
[cocoa-dev-bounces+lrucker=vmware@lists.apple.com] on behalf of Steve
Christensen [puns...@mac.com]
Sent: Sunday, May 31, 2015 6:45 PM
To: Alex Zavatone
Cc: Cocoa-Dev List
Subject: Re: Looking at self = [super init].
No, it doesn't make a difference. In both cases the compiler will generate a
test and branch to the method's epilogue. For the = case:
if (self = [super init]) ...
is equivalent to:
if ((self = [super init]) != nil) ...
is equivalent to:
self = [super init];
if (self) ...
is equivalent to:
self = [super init];
if (self != nil) …
They all:
• Call the superclass' -init method.
• Store the result in self.
• Test if self is not equal to nil/zero.
• Branch to method epilogue (or at least past {...}) if not.
The == case that has been mentioned just omits the second step because self
isn't modified by calling [super init]. And the equivalent statements for the
other case (! / ==) do the same thing except that the test step is the inverse.
In my opinion having a macro to replace the self = [super init] idiom saves
you a couple of seconds of typing — once; it obfuscates behavior since you need
to locate the macro to see what it does if you forget; and it is applicable
only to subclasses where you're calling a superclass' -init method. It doesn't
help for, e.g., -initWithCoder:, -initWithFrame:, etc., which then means you
need to come up with a bunch of other macros to handle those cases or you're
special-casing [super init].
Choosing to do an early return or not is up to you. Personally I prefer the if
(self != nil) {...} case, even if the method is long so that I can see
structure. To say more risks getting into a religious discussion that nobody
wins. :)
On May 30, 2015, at 3:20 PM, Alex Zavatone z...@mac.com wrote:
Actually, i was typing by habit and included == instead of = by mistake.
So, while you answered the question, you may have answered the wrong question.
The question is not for
if ( self == [super init])
It's
if ( self = [super init])
How does that change your answer?
On May 30, 2015, at 6:08 PM, Michael David Crawford wrote:
While in principle machine code implementations of subroutines can
return from several different places, in practice they don't. Rather
the compiler's code generator emits a branch instruction to the end of
the subroutine, there there is an epilog.
There are many good reasons for returning from the middle in certain
specific cases; what if the only epilog you need is an rts?
Branching to the epilog could cause a cache miss.
I expect the compiler developers know all about this but don't
typically avail themselves of it because writing compilers is
difficult.
To be clear, the following source code:
- (id) init
{
if ( self == [super init] ) return nil;
// lots of code goes here
return self;
}
... is implemented as something like this, but in machine code:
- (id) init
{
id result;
if ( self == [super init] ){
result = nil;
goto epilog;
}
// lots of code goes here
result = self;
epilog:
return result;
}
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.warplife.com_mdc_d=BQIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=ie7S-J__EKnfyVOBV7-jV2rZ--p47O6vkyTklpDM3h4m=Z8vcdjmsMKlbvM2wCAfNohcqAEcoUBSmr2LdV39oZp8s=0LcsucVzgw_rFosbryao4sTH3L4wj7OecTlM6LeQ3gUe=
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Fri, May 29, 2015 at 6:25 PM, Graham Cox graham@bigpond.com wrote:
On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote:
// We don't care if this gets long.
My take is that you're rewriting a well-recognised idiom to solve a
non-existent problem.
The well-recognised idiom makes it easy to verify it's correct. Hiding a
different construct inside a macro obscures that, making it harder to
verify the code. It's not wrong exactly, just harder to see at a glance
that it's right.
The non-existent problem you're trying to solve is that the gap between a
pair of braces could get large. So what? Early returns can be another
source of bugs, so structural purists would tell you that you shouldn't do
that. Sometimes I think it's justified, but not usually worthwhile. Another
religious issue is whether matching braces should line up or not.
Personally I prefer that they do, at the cost of an extra line. Because you
aren't doing
Re: Looking at self = [super init].
On 30 May 2015, at 02:25, Graham Cox graham@bigpond.com wrote: On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote: // We don't care if this gets long. My take is that you’re rewriting a well-recognised idiom to solve a non-existent problem. The problem is that it makes the init method less readable and more error prone. The well-recognised idiom makes it easy to verify it’s correct. Hiding a different construct inside a macro obscures that, making it harder to verify the code. It’s not “wrong” exactly, just harder to see at a glance that it’s right. The non-existent problem you’re trying to solve is that the gap between a pair of braces could get large. So what? Early returns can be another source of bugs, so structural purists would tell you that you shouldn’t do that. So can extra braces along with just about everything else you write! Source code is for humans, so it should be as readable as you can possibly make it. Macros often hinder that. Unaligned braces hinder that. Multiple statements per line hinder that. Exactly, so make it more readable, to me anyway, unnecessary braces just add to complexity or at least makes the method look more complex than it actually is. Cheers Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 4:52 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary
-- it doesn’t help with namespacing (if a subclass and a superclass both
declare _someVariable with the underscore they will collide just as badly as
if they declare someVariable without one)
Which is not at all, actually:
#import Foundation/Foundation.h
@interface Foo : NSObject
- (void)fooLogAnIvar;
@end
@interface Bar : Foo
- (void)barLogAnIvar;
@end
int main(int argc, const char * argv[]) {
@autoreleasepool {
Bar *bar = [Bar new];
[bar fooLogAnIvar];
[bar barLogAnIvar];
}
return 0;
}
@implementation Foo {
NSString *_anIvar;
}
- (instancetype)init {
self = [super init];
if (self == nil) {
return nil;
}
_anIvar = @Foo;
return self;
}
- (void)fooLogAnIvar {
NSLog(@Foo: _anIvar is %@, _anIvar);
}
@end
@implementation Bar {
NSString *_anIvar;
}
- (instancetype)init {
self = [super init];
if (self == nil) {
return nil;
}
_anIvar = @Bar;
return self;
}
- (void)barLogAnIvar {
NSLog(@Bar: _anIvar is %@, _anIvar);
}
@end
2015-06-01 17:12:16.328 test[17203:2499855] Foo: _anIvar is Foo
2015-06-01 17:12:16.329 test[17203:2499855] Bar: _anIvar is Bar
and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or
self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely,
someObject-obviouslyAnIvar).
Non-underscored ivars vs. local variables, however, are not obvious at all,
especially if the method is large.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
My take on it is that this is somewhat a style issue; and as such is
quasi-religious in nature; with adherents on all sides of the issue with valid
points to make.
But FWIW, my, er, “sect” (to take a metaphor slightly beyond the breaking
point) adheres to something that looks like this (er, coded in Mail.app - take
with appropriate grains of salt):
#define RSHOddBall_randomDictionaryCapacity (100)
@implementation RSHOddBall
-(instancetype)init
{
if(!(self=[super init])) return nil;
someIvar=12345;
someRandomDictionary=[NSMutableDictionary
initWithCapacity:RSHOddBall_randomDictionaryCapacity];
return self;
};
Notes:
I code with the full capabilities of modern IDEs in mind; for example, I don’t
worry about setting off macros in all caps as syntax highlighting takes care
that; and if I see a macro that I don’t immediately know exactly what it does,
well it’s definition is only a command-click away.
I do believe that for readability, braces should be lined up vertically. Yes,
it makes the source code longer - but ‘comeon, we’ve got *very* high resolution
monitors these days, we can fit a *lot* of text on them!
I happen to like an extra semicolon after a closing brace when it’s the end of
the logical block. It’s just the way I like it to look (it feels ‘funny’ to me
to have a statement end without one); the compiler ignores it. YMMV.
Within a class I’ll often use direct ivar access; but outside of it I’ll almost
always use accessors (there are some oddball performance related exceptions to
this, but they are always heavily documented on the variable declarations, and
used in a tightly integrated class-cluster like situation, hence the *almost*
always - but it’s the exception, definitely not the rule). Yes, I know that
there are valid reasons to use accessors within the class, but for most of my
code it’s not warranted. Transforming direct ivar access to use accessors is a
simple regex search and replacement should I need to refactor it. Again, YMMV.
I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary --
it doesn’t help with namespacing (if a subclass and a superclass both declare
_someVariable with the underscore they will collide just as badly as if they
declare someVariable without one) and ivars vs accessors are obvious by
context: [self obviouslyAnAccessor] or self.obviouslyAnAccessor vs
obviouslyAnIvar (or very rarely, someObject-obviouslyAnIvar). I do, however,
use them for doing pseudo-namespacing at levels below the project prefix (as
evidenced by RSHOddBall_randomDictionaryCapacity).
I personally find early returns to be very useful, and also make use of
forward-jumping goto statements sometimes (i.e, goto bail;).
However, when working on somebody else’s code (like, say, an open-source
library); I’ll adopt their coding style, even if some of the things they do
make my eyes itch. ;-)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
I've always used m to prefix ivars: mSpeed, mDistance. I use s
for statics and k for constants.
I'd like to find a good convention for distinguishing properties but
haven't really found one that is appealing to me.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Mon, Jun 1, 2015 at 3:14 PM, Charles Srstka cocoa...@charlessoft.com wrote:
On Jun 1, 2015, at 4:52 PM, Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I don't use underscores to prefix ivars. I think it's ugly, and unnecessary
-- it doesn't help with namespacing (if a subclass and a superclass both
declare _someVariable with the underscore they will collide just as badly as
if they declare someVariable without one)
Which is not at all, actually:
#import Foundation/Foundation.h
@interface Foo : NSObject
- (void)fooLogAnIvar;
@end
@interface Bar : Foo
- (void)barLogAnIvar;
@end
int main(int argc, const char * argv[]) {
@autoreleasepool {
Bar *bar = [Bar new];
[bar fooLogAnIvar];
[bar barLogAnIvar];
}
return 0;
}
@implementation Foo {
NSString *_anIvar;
}
- (instancetype)init {
self = [super init];
if (self == nil) {
return nil;
}
_anIvar = @Foo;
return self;
}
- (void)fooLogAnIvar {
NSLog(@Foo: _anIvar is %@, _anIvar);
}
@end
@implementation Bar {
NSString *_anIvar;
}
- (instancetype)init {
self = [super init];
if (self == nil) {
return nil;
}
_anIvar = @Bar;
return self;
}
- (void)barLogAnIvar {
NSLog(@Bar: _anIvar is %@, _anIvar);
}
@end
2015-06-01 17:12:16.328 test[17203:2499855] Foo: _anIvar is Foo
2015-06-01 17:12:16.329 test[17203:2499855] Bar: _anIvar is Bar
and ivars vs accessors are obvious by context: [self obviouslyAnAccessor] or
self.obviouslyAnAccessor vs obviouslyAnIvar (or very rarely,
someObject-obviouslyAnIvar).
Non-underscored ivars vs. local variables, however, are not obvious at all,
especially if the method is large.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 6/1/2015 2:52 PM, Britt Durbrow wrote:
I personally find early returns to be very useful, and also make use of
forward-jumping goto statements sometimes (i.e, goto bail;).
FWIW, while I embrace both early returns and the goto statement where it
makes sense, for the case you make, I would use a break statement inside
a do block:
#define end_do while (0)
do {
if ( bailCondition ) break;
if ( someOtherBailCondition ) break;
...
} end_do;
This creates another level of indentation, but structurally, that's the
point.
However, when working on somebody else’s code (like, say, an open-source
library); I’ll adopt their coding style, even if some of the things they do
make my eyes itch. ;-)
We are cut from the same cloth, there.
Paul
--
Paul Scott
psc...@skycoast.us
smime.p7s
Description: S/MIME Cryptographic Signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
The paper entitled Goto Considered Harmful - by Dijkstra? - was
criticizing spaghetti code. At the time, commonly used programming
languages did not have control flow statements like if/then/else,
do/while, while or switch/case. Instead, other than fortran's
do/continue you had to roll your own control flow; often it was done
quite poorly.
If you're experienced with coding as well as careful about it, there's
no real good reason that one cannot use goto to create control flow
that's not built-in to the language. Despite that it is commonly
asserted that if you use goto, then you are clueless. That's just
wrong.
Assembly code doesn't really have control flow constructs. You make
them out of gotos - condition or unconditional branches.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Mon, Jun 1, 2015 at 4:05 PM, pscott psc...@skycoast.us wrote:
On 6/1/2015 2:52 PM, Britt Durbrow wrote:
I personally find early returns to be very useful, and also make use of
forward-jumping goto statements sometimes (i.e, goto bail;).
FWIW, while I embrace both early returns and the goto statement where it
makes sense, for the case you make, I would use a break statement inside a
do block:
#define end_do while (0)
do {
if ( bailCondition ) break;
if ( someOtherBailCondition ) break;
...
} end_do;
This creates another level of indentation, but structurally, that's the
point.
However, when working on somebody else's code (like, say, an open-source
library); I'll adopt their coding style, even if some of the things they do
make my eyes itch. ;-)
We are cut from the same cloth, there.
Paul
--
Paul Scott
psc...@skycoast.us
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 18:16, Michael David Crawford mdcrawf...@gmail.com wrote: Assembly code doesn't really have control flow constructs. You make them out of gotos - condition or unconditional branches. But assembly doesn't have to worry about dtors and such. That's probably the biggest reason to avoid goto. Even if your code would be clean with a goto now doesn't mean that some engineer in the future won't come along and add some variable that needs its dtor, but is unaware of the evilness that lurks within. Steve via iPad ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 14:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I happen to like an extra semicolon after a closing brace when it’s the end
of the logical block. It’s just the way I like it to look (it feels ‘funny’
to me to have a statement end without one); the compiler ignores it. YMMV.
The issue here is that you may find it comforting to see ‘;’ at the “end” of a
statement, but it skates right over the ambiguity of when a “{ … }” construct
is to be regard as a “logical block”. The compiler does *not* ignore the “;”
after “}”. The following does *not* compile:
if (…) {…}; else {…};
You can argue that the intermediate ‘;’ not the end of a logical block, but if
a “}” isn’t the end of a logical block, you’ve just changed a stylistic rule
into a syntax rule.
I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary
-- it doesn’t help with namespacing (if a subclass and a superclass both
declare _someVariable with the underscore they will collide just as badly as
if they declare someVariable without one)
The real reason for this convention is something else. In the bad old days
(meaning, more or less, pre-Leopard), there were multiple conflicting
conventions about using “_” for naming. Perhaps it was when the clang compiler
was introduced, I can’t remember exactly, but Apple decreed the current
convention, to work around the inherent unsafety of Obj-C namespacing:
— Private 3rd party instance variables *should* use the underscore.
— Private 3rd party methods *must not* use the underscore.
It’s not really a question of good or bad. It’s more a question of what we were
required to do to avoid future Cocoa frameworks releases from retroactively
breaking our apps.
On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com wrote:
Which is not at all, actually:
The answer is “not at all” only with the modern ABI. 32-bit Mac compilations
will conflict.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Steve - are you saying that C++ destructors aren't called if you use a goto?
It was my understanding that the destructor is called if you go out of
scope for any reason, even if it's a goto.
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Mon, Jun 1, 2015 at 4:39 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jun 1, 2015, at 14:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I happen to like an extra semicolon after a closing brace when it's the end
of the logical block. It's just the way I like it to look (it feels 'funny'
to me to have a statement end without one); the compiler ignores it. YMMV.
The issue here is that you may find it comforting to see ';' at the end of
a statement, but it skates right over the ambiguity of when a { ... }
construct is to be regard as a logical block. The compiler does *not*
ignore the ; after }. The following does *not* compile:
if (...) {...}; else {...};
You can argue that the intermediate ';' not the end of a logical block, but
if a } isn't the end of a logical block, you've just changed a stylistic
rule into a syntax rule.
I don't use underscores to prefix ivars. I think it's ugly, and unnecessary
-- it doesn't help with namespacing (if a subclass and a superclass both
declare _someVariable with the underscore they will collide just as badly as
if they declare someVariable without one)
The real reason for this convention is something else. In the bad old days
(meaning, more or less, pre-Leopard), there were multiple conflicting
conventions about using _ for naming. Perhaps it was when the clang
compiler was introduced, I can't remember exactly, but Apple decreed the
current convention, to work around the inherent unsafety of Obj-C namespacing:
-- Private 3rd party instance variables *should* use the underscore.
-- Private 3rd party methods *must not* use the underscore.
It's not really a question of good or bad. It's more a question of what we
were required to do to avoid future Cocoa frameworks releases from
retroactively breaking our apps.
On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com wrote:
Which is not at all, actually:
The answer is not at all only with the modern ABI. 32-bit Mac compilations
will conflict.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 4:16 PM, Michael David Crawford mdcrawf...@gmail.com wrote: The paper entitled Goto Considered Harmful - by Dijkstra? - was criticizing spaghetti code. At the time, commonly used programming languages did not have control flow statements like if/then/else, do/while, while or switch/case. Instead, other than fortran's do/continue you had to roll your own control flow; often it was done quite poorly. Minor nit... Dijkstra was one of the authors of Algol 60 which had plenty of control flow statements. He explicitly mentions goto with respect to algol in his “considered harmful” note: Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark.” However, he follows that with this: I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C. A. R. Hoare.” which sounds like the “religion” being discussed. My feelings on that topic are private, as I feel most religious beliefs should be :) Marc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 19:01, Michael David Crawford mdcrawf...@gmail.com wrote: Steve - are you saying that C++ destructors aren't called if you use a goto? It was my understanding that the destructor is called if you go out of scope for any reason, even if it's a goto. Hmm, either I'm thinking of something else, or I just can't find the right docs. I just learned to never ever use them, and my life as a developer is just dandy. :) Steve via iPad ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 2 Jun 2015, at 10:15 am, Steve Mills sjmi...@mac.com wrote: It was my understanding that the destructor is called if you go out of scope for any reason, even if it's a goto. Hmm, either I'm thinking of something else, or I just can't find the right docs. I think Michael is correct a dtor is called no matter how the scope that it belongs to is exited. But that doesn’t apply to us as Obj-C developers (not sure if Swift has the concept) as we can’t have stack-based objects. But anyway, the argument is really about readability and not introducing bugs. If you have a complex method whose function can’t be determined at a glance (and that in itself could be a good argument for a refactoring) with multiple exit points rather than one clear exit point at the end, it can often be hard to follow the flow of control. If the function is later changed to return a different type (BOOL becomes int for example) then making sure all your exit points return the right thing is extra work. That said, early returns up front for bad parameters or obvious sanity check failures are likely to be more readable. Overall, the judgement isn’t a rule, it’s about the craft and style of programming. Excessive indentation is bad, but probably on balance to be preferred (IMHO) to multiple exit points. Yes, the compiler turns all of those into a goto anyway (or at least a branch to the final RTS or whatever, it rarely inserts an RTS in the middle), but that’s completely hidden from us as it should be. Maybe this is just down to one’s personal history. If that’s ever included extensive Pascal (as mine does) then early returns and gotos are almost anathema. If you cut your teeth on C-like languages, probably less so. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 6/1/2015 5:05 PM, Marco S Hyman wrote: ... My feelings on that topic are private, as I feel most religious beliefs should be :) It can be shown in a secular way that there are edge cases where a goto in the C language is appropriate, in no small part because C lacks labelled break and continue statements. Avoiding goto in those edge cases would unnecessarily compromise code readability and efficiency. But because there are religious zealots who would disagree with secular arguments, I will say no more on the subject. -- Paul Scott psc...@skycoast.us smime.p7s Description: S/MIME Cryptographic Signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
I quite commonly fix bugs by refactoring all the lengthy routines into several shorter ones. I'll do that especially when I can't determine the cause of a bug; instead I'll just look around for messy source then tidy it up. That has a way of making bugs go away. On 6/1/15, Charles Srstka cocoa...@charlessoft.com wrote: On Jun 1, 2015, at 6:39 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: Which is not at all, actually: The answer is not at all only with the modern ABI. 32-bit Mac compilations will conflict. That's true. Also, code written for the Mac Plus using THINK C 3.0 will conflict. However, compilation targets that people are actually still using in 2015 will not conflict. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com This email sent to mdcrawf...@gmail.com -- Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On Jun 1, 2015, at 10:43 PM, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote: So…. it looks like clang at least is doing the right thing and calling the destructor when the variable goes out of scope. Yep. But I believe with goto you can skip over a constructor--but at least you get a warning. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Among the reasons I've always preferred Mac development is the common
use of CamelCase. I have poor eyesight and commonly eye fatigue as
well, that leads to it being difficult for me to distinguish
underscores from hyphens:
foo = unix_style;
foo = unix-style;
It is for that same reason that I adopted someone else's practice of
putting spaces inside of parentheses:
void foo( int x, char y )
I've done that for decades but I've never seen anyone else do it.
On 6/1/15, Britt Durbrow bdurb...@rattlesnakehillsoftworks.com wrote:
In no particular order:
On Jun 1, 2015, at 7:27 PM, Michael David Crawford mdcrawf...@gmail.com
wrote:
I quite commonly fix bugs by refactoring all the lengthy routines into
several shorter ones.
I have the same rule of thumb - if it's not obvious what's going on, I
should probably think about refactoring it into smaller chunks.
--
On Jun 1, 2015, at 6:09 PM, Graham Cox graham@bigpond.com wrote:
If you have a complex method whose function can't be determined at a
glance (and that in itself could be a good argument for a refactoring)
with multiple exit points rather than one clear exit point at the end, it
can often be hard to follow the flow of control.
Um... don't do that? :-)
Yes, early returns gotos are power tools that can be misused. YMMV, wear
proper personal protective equipment, void where prohibited and/or
uninitialized, not for sale to miners, etc...
...and no, I have no idea why people who dig ore out of the ground shouldn't
be allowed to buy it (I suppose that's what I get for asking a muppet for
legal advice, eh? :-)
--
On Jun 1, 2015, at 4:39 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jun 1, 2015, at 14:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I happen to like an extra semicolon after a closing brace when it's the
end of the logical block. It's just the way I like it to look (it feels
'funny' to me to have a statement end without one); the compiler ignores
it. YMMV.
The issue here is that you may find it comforting to see ';' at the end
of a statement, but it skates right over the ambiguity of when a { ... }
construct is to be regard as a logical block. The compiler does *not*
ignore the ; after }. The following does *not* compile:
if (...) {...}; else {...};
You can argue that the intermediate ';' not the end of a logical block,
but if a } isn't the end of a logical block, you've just changed a
stylistic rule into a syntax rule.
The entire if statement is what I consider a logical block: the else {...}
does not, and indeed cannot, stand alone.
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
};
[anotherObject doesSomethingElseEntirely];
is the same to the compiler as:
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
}
[anotherObject doesSomethingElseEntirely];
or even:
someCondition?[someObject doSomething]:[someObject
doSomeOtherThing],[anotherObject doesSomethingElseEntirely];
although I will say that the readability on the third example does suffer
somewhat. :-)
--
I don't use underscores to prefix ivars. I think it's ugly, and
unnecessary -- it doesn't help with namespacing (if a subclass and a
superclass both declare _someVariable with the underscore they will
collide just as badly as if they declare someVariable without one)
The real reason for this convention is something else. In the bad old days
(meaning, more or less, pre-Leopard), there were multiple conflicting
conventions about using _ for naming. Perhaps it was when the clang
compiler was introduced, I can't remember exactly, but Apple decreed the
current convention, to work around the inherent unsafety of Obj-C
namespacing:
-- Private 3rd party instance variables *should* use the underscore.
-- Private 3rd party methods *must not* use the underscore.
It's not really a question of good or bad. It's more a question of what we
were required to do to avoid future Cocoa frameworks releases from
retroactively breaking our apps.
There were multiple arguments for and against underscores; the namespace
issue is one of them; readability was another. FWIW, once upon a time, Apple
claimed the entire namespace prefixed with an underscore as reserved (for
both instance variables and methods). I believe that the modern runtime does
indeed get around
Re: Looking at self = [super init].
On Jun 1, 2015, at 6:39 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com mailto:cocoa...@charlessoft.com wrote: Which is not at all, actually: The answer is “not at all” only with the modern ABI. 32-bit Mac compilations will conflict. That’s true. Also, code written for the Mac Plus using THINK C 3.0 will conflict. However, compilation targets that people are actually still using in 2015 will not conflict. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
In no particular order:
On Jun 1, 2015, at 7:27 PM, Michael David Crawford mdcrawf...@gmail.com
wrote:
I quite commonly fix bugs by refactoring all the lengthy routines into
several shorter ones.
I have the same rule of thumb - if it’s not obvious what’s going on, I should
probably think about refactoring it into smaller chunks.
—
On Jun 1, 2015, at 6:09 PM, Graham Cox graham@bigpond.com wrote:
If you have a complex method whose function can’t be determined at a glance
(and that in itself could be a good argument for a refactoring) with multiple
exit points rather than one clear exit point at the end, it can often be hard
to follow the flow of control.
Um… don’t do that? :-)
Yes, early returns gotos are power tools that can be misused. YMMV, wear
proper personal protective equipment, void where prohibited and/or
uninitialized, not for sale to miners, etc...
…and no, I have no idea why people who dig ore out of the ground shouldn’t be
allowed to buy it (I suppose that’s what I get for asking a muppet for legal
advice, eh? :-)
—
On Jun 1, 2015, at 4:39 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jun 1, 2015, at 14:52 , Britt Durbrow
bdurb...@rattlesnakehillsoftworks.com wrote:
I happen to like an extra semicolon after a closing brace when it’s the end
of the logical block. It’s just the way I like it to look (it feels ‘funny’
to me to have a statement end without one); the compiler ignores it. YMMV.
The issue here is that you may find it comforting to see ‘;’ at the “end” of
a statement, but it skates right over the ambiguity of when a “{ … }”
construct is to be regard as a “logical block”. The compiler does *not*
ignore the “;” after “}”. The following does *not* compile:
if (…) {…}; else {…};
You can argue that the intermediate ‘;’ not the end of a logical block, but
if a “}” isn’t the end of a logical block, you’ve just changed a stylistic
rule into a syntax rule.
The entire if statement is what I consider a logical block: the else {...} does
not, and indeed cannot, stand alone.
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
};
[anotherObject doesSomethingElseEntirely];
is the same to the compiler as:
if(someCondition)
{
[someObject doSomething];
}
else
{
[someObject doSomeOtherThing];
}
[anotherObject doesSomethingElseEntirely];
or even:
someCondition?[someObject doSomething]:[someObject
doSomeOtherThing],[anotherObject doesSomethingElseEntirely];
although I will say that the readability on the third example does suffer
somewhat. :-)
—
I don’t use underscores to prefix ivars. I think it’s ugly, and unnecessary
-- it doesn’t help with namespacing (if a subclass and a superclass both
declare _someVariable with the underscore they will collide just as badly as
if they declare someVariable without one)
The real reason for this convention is something else. In the bad old days
(meaning, more or less, pre-Leopard), there were multiple conflicting
conventions about using “_” for naming. Perhaps it was when the clang
compiler was introduced, I can’t remember exactly, but Apple decreed the
current convention, to work around the inherent unsafety of Obj-C namespacing:
— Private 3rd party instance variables *should* use the underscore.
— Private 3rd party methods *must not* use the underscore.
It’s not really a question of good or bad. It’s more a question of what we
were required to do to avoid future Cocoa frameworks releases from
retroactively breaking our apps.
There were multiple arguments for and against underscores; the namespace issue
is one of them; readability was another. FWIW, once upon a time, Apple claimed
the entire namespace prefixed with an underscore as reserved (for both instance
variables and methods). I believe that the modern runtime does indeed get
around the issue with ivars (I don’t have a documentation reference to point
to, but a quick check in Xcode indicates this; as does Charles Srstka’s posted
code).
—
On Jun 1, 2015, at 7:11 PM, Charles Srstka cocoa...@charlessoft.com wrote:
On Jun 1, 2015, at 6:39 PM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
On Jun 1, 2015, at 15:14 , Charles Srstka cocoa...@charlessoft.com wrote:
Which is not at all, actually:
The answer is “not at all” only with the modern ABI. 32-bit Mac compilations
will conflict.
That’s true. Also, code written for the Mac Plus using THINK C 3.0 will
Re: Looking at self = [super init].
No, it doesn't make a difference. In both cases the compiler will generate a
test and branch to the method's epilogue. For the = case:
if (self = [super init]) ...
is equivalent to:
if ((self = [super init]) != nil) ...
is equivalent to:
self = [super init];
if (self) ...
is equivalent to:
self = [super init];
if (self != nil) …
They all:
• Call the superclass' -init method.
• Store the result in self.
• Test if self is not equal to nil/zero.
• Branch to method epilogue (or at least past {...}) if not.
The == case that has been mentioned just omits the second step because self
isn't modified by calling [super init]. And the equivalent statements for the
other case (! / ==) do the same thing except that the test step is the inverse.
In my opinion having a macro to replace the self = [super init] idiom saves
you a couple of seconds of typing — once; it obfuscates behavior since you need
to locate the macro to see what it does if you forget; and it is applicable
only to subclasses where you're calling a superclass' -init method. It doesn't
help for, e.g., -initWithCoder:, -initWithFrame:, etc., which then means you
need to come up with a bunch of other macros to handle those cases or you're
special-casing [super init].
Choosing to do an early return or not is up to you. Personally I prefer the if
(self != nil) {...} case, even if the method is long so that I can see
structure. To say more risks getting into a religious discussion that nobody
wins. :)
On May 30, 2015, at 3:20 PM, Alex Zavatone z...@mac.com wrote:
Actually, i was typing by habit and included == instead of = by mistake.
So, while you answered the question, you may have answered the wrong question.
The question is not for
if ( self == [super init])
It's
if ( self = [super init])
How does that change your answer?
On May 30, 2015, at 6:08 PM, Michael David Crawford wrote:
While in principle machine code implementations of subroutines can
return from several different places, in practice they don't. Rather
the compiler's code generator emits a branch instruction to the end of
the subroutine, there there is an epilog.
There are many good reasons for returning from the middle in certain
specific cases; what if the only epilog you need is an rts?
Branching to the epilog could cause a cache miss.
I expect the compiler developers know all about this but don't
typically avail themselves of it because writing compilers is
difficult.
To be clear, the following source code:
- (id) init
{
if ( self == [super init] ) return nil;
// lots of code goes here
return self;
}
... is implemented as something like this, but in machine code:
- (id) init
{
id result;
if ( self == [super init] ){
result = nil;
goto epilog;
}
// lots of code goes here
result = self;
epilog:
return result;
}
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Fri, May 29, 2015 at 6:25 PM, Graham Cox graham@bigpond.com wrote:
On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote:
// We don't care if this gets long.
My take is that you're rewriting a well-recognised idiom to solve a
non-existent problem.
The well-recognised idiom makes it easy to verify it's correct. Hiding a
different construct inside a macro obscures that, making it harder to
verify the code. It's not wrong exactly, just harder to see at a glance
that it's right.
The non-existent problem you're trying to solve is that the gap between a
pair of braces could get large. So what? Early returns can be another
source of bugs, so structural purists would tell you that you shouldn't do
that. Sometimes I think it's justified, but not usually worthwhile. Another
religious issue is whether matching braces should line up or not.
Personally I prefer that they do, at the cost of an extra line. Because you
aren't doing that, your long distance between braces is bothering you,
because you're losing track of where it started (I assume that's why it's
bothering you). If you line up the braces that is much less of an issue.
Source code is for humans, so it should be as readable as you can possibly
make it. Macros often hinder that. Unaligned braces hinder that. Multiple
statements per line hinder that.
Factoring code helps, so I'd suggest that's the better way to solve this.
(and it's also beneficial when it comes to making sure that -initWithCoder:
and other initializers that don't correctly follow the designated
initializer rule can get access to your common initialization. While this
is rarely a problem, I did notice that the recent change to encourage the
use of -initWithCoder: for unpacking NSViews from a nib breaks this
long-standing rule and so a common
Re: Looking at self = [super init].
While in principle machine code implementations of subroutines can
return from several different places, in practice they don't. Rather
the compiler's code generator emits a branch instruction to the end of
the subroutine, there there is an epilog.
There are many good reasons for returning from the middle in certain
specific cases; what if the only epilog you need is an rts?
Branching to the epilog could cause a cache miss.
I expect the compiler developers know all about this but don't
typically avail themselves of it because writing compilers is
difficult.
To be clear, the following source code:
- (id) init
{
if ( self == [super init] ) return nil;
// lots of code goes here
return self;
}
... is implemented as something like this, but in machine code:
- (id) init
{
id result;
if ( self == [super init] ){
result = nil;
goto epilog;
}
// lots of code goes here
result = self;
epilog:
return result;
}
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Fri, May 29, 2015 at 6:25 PM, Graham Cox graham@bigpond.com wrote:
On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote:
// We don't care if this gets long.
My take is that you're rewriting a well-recognised idiom to solve a
non-existent problem.
The well-recognised idiom makes it easy to verify it's correct. Hiding a
different construct inside a macro obscures that, making it harder to verify
the code. It's not wrong exactly, just harder to see at a glance that it's
right.
The non-existent problem you're trying to solve is that the gap between a
pair of braces could get large. So what? Early returns can be another source
of bugs, so structural purists would tell you that you shouldn't do that.
Sometimes I think it's justified, but not usually worthwhile. Another
religious issue is whether matching braces should line up or not. Personally
I prefer that they do, at the cost of an extra line. Because you aren't doing
that, your long distance between braces is bothering you, because you're
losing track of where it started (I assume that's why it's bothering you). If
you line up the braces that is much less of an issue.
Source code is for humans, so it should be as readable as you can possibly
make it. Macros often hinder that. Unaligned braces hinder that. Multiple
statements per line hinder that.
Factoring code helps, so I'd suggest that's the better way to solve this.
(and it's also beneficial when it comes to making sure that -initWithCoder:
and other initializers that don't correctly follow the designated initializer
rule can get access to your common initialization. While this is rarely a
problem, I did notice that the recent change to encourage the use of
-initWithCoder: for unpacking NSViews from a nib breaks this long-standing
rule and so a common init method that both can call is a simple workaround).
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Actually, i was typing by habit and included == instead of = by mistake.
So, while you answered the question, you may have answered the wrong question.
The question is not for
if ( self == [super init])
It's
if ( self = [super init])
How does that change your answer?
On May 30, 2015, at 6:08 PM, Michael David Crawford wrote:
While in principle machine code implementations of subroutines can
return from several different places, in practice they don't. Rather
the compiler's code generator emits a branch instruction to the end of
the subroutine, there there is an epilog.
There are many good reasons for returning from the middle in certain
specific cases; what if the only epilog you need is an rts?
Branching to the epilog could cause a cache miss.
I expect the compiler developers know all about this but don't
typically avail themselves of it because writing compilers is
difficult.
To be clear, the following source code:
- (id) init
{
if ( self == [super init] ) return nil;
// lots of code goes here
return self;
}
... is implemented as something like this, but in machine code:
- (id) init
{
id result;
if ( self == [super init] ){
result = nil;
goto epilog;
}
// lots of code goes here
result = self;
epilog:
return result;
}
Michael David Crawford, Consulting Software Engineer
mdcrawf...@gmail.com
http://www.warplife.com/mdc/
Available for Software Development in the Portland, Oregon Metropolitan
Area.
On Fri, May 29, 2015 at 6:25 PM, Graham Cox graham@bigpond.com wrote:
On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote:
// We don't care if this gets long.
My take is that you're rewriting a well-recognised idiom to solve a
non-existent problem.
The well-recognised idiom makes it easy to verify it's correct. Hiding a
different construct inside a macro obscures that, making it harder to verify
the code. It's not wrong exactly, just harder to see at a glance that it's
right.
The non-existent problem you're trying to solve is that the gap between a
pair of braces could get large. So what? Early returns can be another source
of bugs, so structural purists would tell you that you shouldn't do that.
Sometimes I think it's justified, but not usually worthwhile. Another
religious issue is whether matching braces should line up or not. Personally
I prefer that they do, at the cost of an extra line. Because you aren't
doing that, your long distance between braces is bothering you, because
you're losing track of where it started (I assume that's why it's bothering
you). If you line up the braces that is much less of an issue.
Source code is for humans, so it should be as readable as you can possibly
make it. Macros often hinder that. Unaligned braces hinder that. Multiple
statements per line hinder that.
Factoring code helps, so I'd suggest that's the better way to solve this.
(and it's also beneficial when it comes to making sure that -initWithCoder:
and other initializers that don't correctly follow the designated
initializer rule can get access to your common initialization. While this is
rarely a problem, I did notice that the recent change to encourage the use
of -initWithCoder: for unpacking NSViews from a nib breaks this
long-standing rule and so a common init method that both can call is a
simple workaround).
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawf...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
This email sent to z...@mac.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Il giorno 29/mag/2015, alle ore 19:38, Alex Zavatone z...@mac.com ha
scritto:
DOH. Good catch. Sorry, was typing out by hand instead of copying and
pasting. I'm actually returning nil in the real class.
So, that should be this:
- (id)init {
if (self != [super init]) {
return nil;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
what if [super init] returned something different than self, yet not nil?
In that case, your code wouldn’t be correct, as a general rule...
--
Simone Tellini
http://tellini.info
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 2:16 PM, Scott Ribe wrote:
On May 29, 2015, at 11:49 AM, Alex Zavatone z...@mac.com wrote:
Would this handle it properly?
if (!(self = [super init])) {
return nil;
}
Yes.
if (!(self == [super init]))
No. But not sure whether you were asking about that or not…
Typing == by habit. My mistake.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 12:17 PM, Alex Zavatone z...@mac.com wrote: Typing == by habit. My mistake. Ah, *NOW* the conversation makes sense ;-) -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
Was just looking at good old object initialization and came across a stupid
idea.
For most object initialization, we do this:
- (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self;
}
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for organization,
but if you're passing objects into into your init method, then you're passing
more data again and the code could get less cleaner looking than it could be.
So, I thought, why don't we check if self != [super init] and then
immediately return if that is the case?
That would change object initialization to this:
- (id)init {
if (self != [super init]) {
return;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
You must at least returns nil in the fast path, else the compiler will not be
happy.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 1:35 PM, Jean-Daniel Dupas wrote:
Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
Was just looking at good old object initialization and came across a stupid
idea.
For most object initialization, we do this:
- (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self;
}
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for
organization, but if you're passing objects into into your init method, then
you're passing more data again and the code could get less cleaner looking
than it could be.
So, I thought, why don't we check if self != [super init] and then
immediately return if that is the case?
That would change object initialization to this:
- (id)init {
if (self != [super init]) {
return;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
You must at least returns nil in the fast path, else the compiler will not be
happy.
DOH. Good catch. Sorry, was typing out by hand instead of copying and
pasting. I'm actually returning nil in the real class.
So, that should be this:
- (id)init {
if (self != [super init]) {
return nil;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 11:02 AM, Alex Zavatone z...@mac.com wrote: Regarding Daniel's next email, yeah, I kind of really dislike the extra indent for the entire init function. It just seems so wrong. That’s sort of a religious issue. Some people think early returns from functions are wrong, because they make the flow of control less structured. (Pascal doesn’t have a ‘return’ statement at all, at least none of the dialects I ever used.) IIRC some functional languages don’t support early-return either. I tend to prefer early returns, but at the same time I agree that they are sometimes confusing, especially for someone reading a function for the first time. FWIW, the Google style guide says to use early returns for quick-reject tests at the start of a function, which is what we’re talking about here. On the other hand, the structure of an Obj-C ‘init’ method is such a well-known idiom that I’m reluctant to mess with it. Everyone knows how control flows in a normal init method, so if they se one that doesn’t look like that, it takes a bit longer to figure out what’s going on. Not to mention that putting assignments in ‘if’ statements is EVIL, even if it does save you a line of code. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 1:40 PM, Jean-Daniel Dupas wrote:
Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
Was just looking at good old object initialization and came across a stupid
idea.
For most object initialization, we do this:
- (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self;
}
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for
organization, but if you're passing objects into into your init method, then
you're passing more data again and the code could get less cleaner looking
than it could be.
So, I thought, why don't we check if self != [super init] and then
immediately return if that is the case?
That would change object initialization to this:
- (id)init {
if (self != [super init]) {
return;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
And now that a reread the code, it is patently wrong.
if (self = [super init]) is a assignment to self not a comparison.
If you want to do a fast path, you have to do
self = [super init];
if (!self)
return nil;
Thanks much. I knew there was something I was missing there that one of you
would see.
Would this handle it properly?
if (!(self = [super init])) {
return nil;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
Le 29 mai 2015 à 19:22, Alex Zavatone z...@mac.com a écrit :
Was just looking at good old object initialization and came across a stupid
idea.
For most object initialization, we do this:
- (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self;
}
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for organization,
but if you're passing objects into into your init method, then you're passing
more data again and the code could get less cleaner looking than it could be.
So, I thought, why don't we check if self != [super init] and then
immediately return if that is the case?
That would change object initialization to this:
- (id)init {
if (self != [super init]) {
return;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
And now that a reread the code, it is patently wrong.
if (self = [super init]) is a assignment to self not a comparison.
If you want to do a fast path, you have to do
self = [super init];
if (!self)
return nil;
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 11:49 AM, Alex Zavatone z...@mac.com wrote:
Would this handle it properly?
if (!(self = [super init])) {
return nil;
}
Yes.
if (!(self == [super init]))
No. But not sure whether you were asking about that or not…
--
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Looking at self = [super init].
Was just looking at good old object initialization and came across a stupid
idea.
For most object initialization, we do this:
- (id)init {
if (self = [super init]) {
// Set up stuff here.
// this could get long.
}
return self;
}
in some cases, the set up within the parens could get pretty long. In cases
like that, I generally set up another method to handle that for organization,
but if you're passing objects into into your init method, then you're passing
more data again and the code could get less cleaner looking than it could be.
So, I thought, why don't we check if self != [super init] and then immediately
return if that is the case?
That would change object initialization to this:
- (id)init {
if (self != [super init]) {
return;
}
// Set up stuff here.
// We don't care if this gets long.
// We really don't. This could go on and on.
return self;
}
We probably could make a little macro to replace that if clause and return
statement if desired, but that's besides the point.
With regards to doing object initialization this way, is there a good reason
why we don't do it this way?
I'm not smoking crack here, am I? Does this actually seem like a good idea?
Interested in your views on this.
Cheers and happy Friday,
Alex Zavatone
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 10:35 , Jean-Daniel Dupas mail...@xenonium.com wrote:
You must at least returns nil in the fast path, else the compiler will not be
happy.
Shame on you, Jean-Daniel, for not spotting the other error!
On May 29, 2015, at 10:22 , Alex Zavatone z...@mac.com wrote:
if (self != [super init]) {
return;
}
The opposite of ‘if (self = [super init])’ isn’t ‘if (self != [super init])’.
The correct code is:
self = [super init];
if (self == nil)
return nil;
I'm not smoking crack here, am I?
We only have your word for it.
Does this actually seem like a good idea?
Of course it’s a good idea (minus the two glaring bugs).
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 1:42 PM, Quincey Morris wrote:
On May 29, 2015, at 10:35 , Jean-Daniel Dupas mail...@xenonium.com wrote:
You must at least returns nil in the fast path, else the compiler will not
be happy.
Shame on you, Jean-Daniel, for not spotting the other error!
On May 29, 2015, at 10:22 , Alex Zavatone z...@mac.com wrote:
if (self != [super init]) {
return;
}
The opposite of ‘if (self = [super init])’ isn’t ‘if (self != [super init])’.
The correct code is:
self = [super init];
if (self == nil)
return nil;
I'm not smoking crack here, am I?
We only have your word for it.
Does this actually seem like a good idea?
Of course it’s a good idea (minus the two glaring bugs).
Heh, yeah, it's been a LNG week. I certainly can't see through the glare
too well.
Regarding Daniel's next email, yeah, I kind of really dislike the extra indent
for the entire init function. It just seems so wrong.
Glad I asked. I'm certainly not the first person to come across this.
Daniel's friend's solution seems good. However, the !self comment shows the
same error Simon points out below.
Also, Simon points out another error in my assumption.
what if [super init] returned something different than self, yet not nil?
In that case, your code wouldn’t be correct, as a general rule...
Hmmm. This little comparison does flip the BOOL.
if (!(self == [super init]))
Anyway, thanks for the Friday feedback and observations.
Cheers,
Alex Zavatone
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 2:19 PM, Jens Alfke wrote:
Not to mention that putting assignments in ‘if’ statements is EVIL, even if
it does save you a line of code.
—Jens
I tend to agree with you as it makes the code just a little more obtuse. As an
example, I went through this entire email thread typing == by habit instead of
=.
However, having to go through a few lines just for an init seems like a lot of
noise to add to every object initialization. Seems like we could come up with
some sort of macro that would replace that and provide an early return.
Having to indent the statements one extra level in an init just seems like an
obvious case of we're doing this wrong - isn't there any way we can do this
better? That and being able to handle leave with an early return make the
init method feel nicer to me. I'm just a little too tired at the moment to put
a solution together that doesn't fail badly in the non perfect case.
I was thinking about this statement though:
if (! (self = [super init]) ) {
return nil;
}
// start initing stuff
return self;
Then there must be a nice way to step back to the original question and see if
that could be a macro. I'm sure someone's done that already as well.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On 30 May 2015, at 3:22 am, Alex Zavatone z...@mac.com wrote: // We don't care if this gets long. My take is that you’re rewriting a well-recognised idiom to solve a non-existent problem. The well-recognised idiom makes it easy to verify it’s correct. Hiding a different construct inside a macro obscures that, making it harder to verify the code. It’s not “wrong” exactly, just harder to see at a glance that it’s right. The non-existent problem you’re trying to solve is that the gap between a pair of braces could get large. So what? Early returns can be another source of bugs, so structural purists would tell you that you shouldn’t do that. Sometimes I think it’s justified, but not usually worthwhile. Another religious issue is whether matching braces should line up or not. Personally I prefer that they do, at the cost of an extra line. Because you aren’t doing that, your long distance between braces is bothering you, because you’re losing track of where it started (I assume that’s why it’s bothering you). If you line up the braces that is much less of an issue. Source code is for humans, so it should be as readable as you can possibly make it. Macros often hinder that. Unaligned braces hinder that. Multiple statements per line hinder that. Factoring code helps, so I’d suggest that’s the better way to solve this. (and it’s also beneficial when it comes to making sure that -initWithCoder: and other initializers that don’t correctly follow the designated initializer rule can get access to your common initialization. While this is rarely a problem, I did notice that the recent change to encourage the use of -initWithCoder: for unpacking NSViews from a nib breaks this long-standing rule and so a common init method that both can call is a simple workaround). —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 11:17 AM, Alex Zavatone z...@mac.com wrote:
On May 29, 2015, at 2:16 PM, Scott Ribe wrote:
On May 29, 2015, at 11:49 AM, Alex Zavatone z...@mac.com wrote:
Would this handle it properly?
if (!(self = [super init])) {
return nil;
}
Yes.
if (!(self == [super init]))
No. But not sure whether you were asking about that or not…
Typing == by habit. My mistake.
Our style is
self = [super init];
if (!self) {
return nil;
}
because == is a habit, and that ! in (!( is hard to spot when it’s accidentally
left out.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Looking at self = [super init].
On May 29, 2015, at 12:34 PM, Alex Zavatone z...@mac.com wrote: Then there must be a nice way to step back to the original question and see if that could be a macro. #define CHECKED_SUPER_INIT if (!(self = [super init])) return nil You *could* wrap it in the do expression to make it workable in if expressions etc, but that seems like overkill here, since you would always run this on its own at the top of a block. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
