• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa class extension best practice
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa class extension best practice


  • Subject: Re: Cocoa class extension best practice
  • From: Andy Lee <email@hidden>
  • Date: Wed, 16 Oct 2013 14:45:41 -0400

On Oct 16, 2013, at 2:09 PM, Steve Mills <email@hidden> wrote:

> On Oct 16, 2013, at 12:45:49, Andy Lee <email@hidden> wrote:
>
>> I still don't see what mutability has to do with it, but that's a side issue.
>
> The mutability doesn't matter. I'm just emphasizing that the internal array is mutable and this is returning a COPY of that array (which happens to be immutable).

I see.

>
>> I would too.
>>
>> I suspect you can safely use the instance variable, but if you're concerned about the fact that it's undocumented, or that Apple could in theory move it to the @implementation so that it's no longer visible to your code, you can accomplish the same using numberOfItems and itemAtIndex:, as I mentioned earlier.  Then you're using totally public API *and* this particular method no longer instantiates any objects.  Either way, I'd add a clarifying comment.
>
> That's a good point. I'm guessing the author of this code used itemArray simply because it was an easy way to use the new "in" for loop mechanism.

Well, that is the most natural and concise way to do it other than directly accessing the ivar, which by now it should be clear, is a bad idea.  You probably wouldn't have given itemArray a second thought except for the memory issues you observed.

If I'm understanding what's been figured out so far, it seems itemArray itself doesn't leak.  What I'm not clear on is whether your NSMenu methods (or more precisely, the places where those methods are called) have anything to do with your memory issues, or if they are a red herring.  If you change the methods so they don't instantiate any objects -- heck, if they always return nil -- does your memory footprint still keep increasing?

Is the growing memory footprint definitely an indication of a problem, or could there be a cache somewhere whose *purpose* is to grow?  If memory usage is growing out of hand, again I'd suggest using heapshots to see what objects are being added to cause the footprint to increase when you weren't expecting it to.

Speaking of which, I've had a memory issue reported and should really be taking a look at that... For some reason my bugs are boring while other people's are interesting. :)

--Andy



_______________________________________________

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


References: 
 >Cocoa class extension best practice (From: Steve Mills <email@hidden>)
 >Re: Cocoa class extension best practice (From: Kyle Sluder <email@hidden>)
 >Re: Cocoa class extension best practice (From: Steve Mills <email@hidden>)
 >Re: Cocoa class extension best practice (From: Graham Cox <email@hidden>)
 >Re: Cocoa class extension best practice (From: "Mills, Steve" <email@hidden>)
 >Re: Cocoa class extension best practice (From: Graham Cox <email@hidden>)
 >Re: Cocoa class extension best practice (From: Steve Mills <email@hidden>)
 >Re: Cocoa class extension best practice (From: Jens Alfke <email@hidden>)
 >Re: Cocoa class extension best practice (From: Ken Thomases <email@hidden>)
 >Re: Cocoa class extension best practice (From: Steve Mills <email@hidden>)
 >Re: Cocoa class extension best practice (From: Ken Thomases <email@hidden>)
 >Re: Cocoa class extension best practice (From: Steve Mills <email@hidden>)
 >Re: Cocoa class extension best practice (From: Andy Lee <email@hidden>)
 >Re: Cocoa class extension best practice (From: Steve Mills <email@hidden>)

  • Prev by Date: Re: Question about matrix of possibilities
  • Next by Date: Re: Cocoa class extension best practice
  • Previous by thread: Re: Cocoa class extension best practice
  • Next by thread: Re: Cocoa class extension best practice
  • Index(es):
    • Date
    • Thread