Re: Looking at self = [super init].
Re: Looking at self = [super init].
- Subject: Re: Looking at self = [super init].
- From: Britt Durbrow <email@hidden>
- Date: Mon, 01 Jun 2015 21:43:52 -0700
In no particular order:
> On Jun 1, 2015, at 7:27 PM, Michael David Crawford <email@hidden> 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 <email@hidden> 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 <email@hidden> wrote:
>
> 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.
>
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 <email@hidden> wrote:
>
> On Jun 1, 2015, at 6:39 PM, Quincey Morris <email@hidden> wrote:
>>
>> 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.
>
> 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
Although I have the luxury of requiring modern runtime capable systems, some people do still have to target the old runtime…
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.
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.
> On Jun 1, 2015, at 3:14 PM, Charles Srstka <email@hidden> 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… :-)
Also, the syntax highlighting does render (at least on my setup) in different colors for local variables and instance variables.
—————————————————————————————————————————————————————————————
>> 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
I just did a test with this code:
#import <Foundation/Foundation.h>
#import "stdio.h"
class testClass
{
public:
testClass()
{
puts("Constructor called.");
};
~testClass()
{
puts("Destructor called.");
};
void someFunction()
{
puts("someFunction called.");
};
};
int main(int argc, const char * argv[])
{
@autoreleasepool
{
puts("Starting...");
if(argc)
{
testClass t;
if(argc==1) goto done;
t.someFunction();
};
done:
puts("Done!\n");
};
return 0;
};
and got this output:
Starting...
Constructor called.
Destructor called.
Done!
So…. it looks like clang at least is doing the right thing and calling the destructor when the variable goes out of scope.
_______________________________________________
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