Re: Found It - Problem with Outline View and Manual Memory Management
On 28 May 2015, at 17:56, Kyle Sluder k...@ksluder.com wrote:
On Thu, May 28, 2015, at 08:37 AM, Dave wrote:
Hi,
This is from Apple Sample Code so I thought something as fundamental as
this would have been dealt with correctly. This is the copy method inside
the “ImageAndTextCell” class,
-(id) copyWithZone:(NSZone*) zone
{
ImageAndTextCell *cell = (BJImageAndTextCell*) [super copyWithZone:zone];
cell.pTextCellImage = self.pTextCellImage;
return cell;
}
I'm guessing this is taken from the SourceView sample? That project uses
ARC. If you are using ARC in your own project, sending -copyWithZone: to
super should do the right thing. (Yes, whether super does the right
thing is based on whether _your class_ is compiled using ARC.)
In any event, please consider moving to a view-based table view. Then
you don't need to use a custom cell class at all.
--Kyle Sluder
SourceView is ARC based, but the project I extracted the View Controller and
Utility Classes into is non ARC. Given that the project is non-ARC, is the
copyWithZone method above valid?
In any event, please consider moving to a view-based table view. Then
you don't need to use a custom cell class at all.
I probably will at some point, but I’d like to get this working ok first,
although it seems ok at the moment.
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: Rotate a standard Cocoa control?
On 29 May 2015, at 2:03 pm, Jerry Krinock je...@ieee.org wrote: But Graham’s GCVolumeControl is still way better than circular NSSlider no matter how you rotate it.) Kind of you Jerry. Make sure you grab the latest if you intend to use it - I made a useful number of improvements over the first version. —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
NSTextView + NSTextTable print pagination query
I am printing my NSTableView by constructing an NSTextTable attributed string representation and storing that into an NSTextView. This works great and it paginates correctly :i.e.: table rows don’t get split between pages. My NSTextTable has a header row and this is output at the start of each table. However I would also like to print this header row at the top of each page if appropriate i.e.: where a NSTextTable spans a page break. I cannot quite figure out where in the text system I should be looking to try and accomplish this. A prod in the right direction would be appreciated. Thanks Jonathan ___ 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: NSDocumentTitlebarPopoverViewController zombie on Yosemite
Good to know. Duplicate radar filed, rdar://problem/21145343. We saw the same issue starting with 10.10.3 and continuing through current 10.10.4 builds. Write up a radar and reference radar://problem/20368338 as a duplicate instance. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ On May 28, 2015, at 11:34 AM, Matthew LeRoy mle...@minitab.commailto:mle...@minitab.com wrote: Hi, Anybody know anything about NSDocumentTitlebarPopoverViewController, and/or why I’m getting application crashes due to a zombie’d instance thereof? Document-based app, Deployment Target and SDK both 10.8. Built using Xcode 5.1.1 (5B1008) on Yosemite 10.10.3; running on the same system. Here’s what I do: 1. Run my app. 2. Open an existing document from disk. 3. Click on the document name in the window’s titlebar to open the Document name/tag/location popover. 4. Wait a second or two. 5. Click elsewhere in my document window to close the popover. 6. Crash. Sometimes the crash happens immediately after the popover disappears; other times it happens 1-3 seconds later. It doesn’t happen every time, but always within two to three repetitions of steps 3–5. Here’s the stack trace when it crashes: frame #0: 0x7fff84a13d20 CoreFoundation`___forwarding___ + 768 frame #1: 0x7fff84a13998 CoreFoundation`__forwarding_prep_0___ + 120 frame #2: 0x7fff92603547 ViewBridge`-[NSRemoteViewBase endAllModalSessions:] + 177 frame #3: 0x7fff925fbe74 ViewBridge`-[NSRemoteViewBase viewWillMoveToWindow:] + 367 frame #4: 0x7fff864b90de AppKit`-[NSView _setWindow:] + 257 frame #5: 0x7fff849ea705 CoreFoundation`__53-[__NSArrayM enumerateObjectsWithOptions:usingBlock:]_block_invoke + 133 frame #6: 0x7fff849e9e09 CoreFoundation`-[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 313 frame #7: 0x7fff86c3d474 AppKit`__21-[NSView _setWindow:]_block_invoke735 + 169 frame #8: 0x7fff864b9c54 AppKit`-[NSView _setWindow:] + 3191 frame #9: 0x7fff864c73d7 AppKit`-[NSVisualEffectView _setWindow:] + 214 frame #10: 0x7fff86722747 AppKit`-[NSPopoverFrame _setWindow:] + 111 frame #11: 0x7fff8670961f AppKit`-[NSWindow dealloc] + 1201 frame #12: 0x7fff8679c9f5 AppKit`-[_NSPopoverWindow dealloc] + 74 frame #13: 0x7fff864b68cc AppKit`-[NSWindow release] + 193 frame #14: 0x7fff8497fdb0 CoreFoundation`CFRelease + 304 frame #15: 0x7fff849a0bbd CoreFoundation`-[__NSArrayI dealloc] + 125 frame #16: 0x7fff9211d89c libobjc.A.dylib`objc_object::sidetable_release(bool) + 236 frame #17: 0x7fff92103e8f libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 575 frame #18: 0x7fff849a16f2 CoreFoundation`_CFAutoreleasePoolPop + 50 frame #19: 0x7fff8c1c1762 Foundation`-[NSAutoreleasePool drain] + 153 frame #20: 0x7fff8650ccc1 AppKit`-[NSApplication run] + 800 frame #21: 0x7fff86489354 AppKit`NSApplicationMain + 1832 After enabling Zombie Objects, I get the following in the console: 2015-05-28 14:19:58.291 MyApp[23684:2561441] *** -[NSDocumentTitlebarPopoverViewController isKindOfClass:]: message sent to deallocated instance 0x60146f60 Google is no help, although it did uncover the following tweet from just a few days ago: https://twitter.com/tonyarnold/status/603424801152086017. Anybody run across this before, or have any thoughts on what the problem could be and/or how to debug? Thanks! Matt ___ 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
