Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Quincey Morris <email@hidden>
- Date: Mon, 01 Jun 2015 23:39:55 +0000
On Jun 1, 2015, at 14:52 , Britt Durbrow <email@hidden> 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 <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden