• 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: substring return a new string?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: substring return a new string?


  • Subject: Re: substring return a new string?
  • From: Marco Scheurer <email@hidden>
  • Date: Thu, 18 Mar 2004 17:32:56 +0100

On Mar 18, 2004, at 2:05 PM, Ondra Cada wrote:

Well... I would beg to differ a bit. IMHO, this design is truly oft-used, but (not to be considered a bug) only in cases where efficiency is not extremely important.

Presumed the speed/space is paramount, especially in contexts where it is probable the accessor may be used often and by more different modules, the logic -- in my personal opinion -- should generally (* see below) change to

@interface ... {
NSArray *arrayCache;
}
...
@implementation ...
...
-(NSArray*)someArray {
if (!arrayCache) {
NSMutableArray *someArray = [NSMutableArray array];
// some logic and [someArray addObject:anObject];
arrayCache=[someArray copy];
}
return arrayCache;
}

including of course the logic which would release&nil the arrayCache whenever the data change so that the aray result would too, and in dealloc.

OK, and in this case a copy could make sense (and not just be paranoia that the user will realize that he has a mutable array which he can change) if you expect that the receiver will often make a copy of the result, and that the cache will be valid across many invocations.

(*) Of course, there are situations in which this approach is bad; my estimation though is that in a vast majority of cases (of those where efficiency is important) it's better than the plain returning the mutable array without saying so. Nevertheless, if the speed/space are very important and this approach seems wrong,

It's not necessarily a space/speed issue. Keeping a cache and knowing when to invalidate it can be difficult. The returned array may be constructed in a complicated algorithm that could depend on the state of of other objects etc... Looking at my code I can see many places where arrays are constructed on the fly, and not that many where I decided to use a cache (YMMV).

so far as I can say the only remaining possibility is to *declare* the method returning mutable data, and *document* the fact it is always freshly-created: let then the client decide what to do with it:

@interface ...
...
-(NSMutableArray*)someArray; // created each time the message is sent, not stored then
...
// implementation exactly as you suggested.

Certainly not! Declaring the method as returning NSMutableArray documents the fact that the user can modify the returned array. This is most likely not what you want.

Marco Scheurer
Sen:te, Lausanne, Switzerland http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: substring return a new string?
      • From: Ondra Cada <email@hidden>
References: 
 >Re: substring return a new string? (From: Ondra Cada <email@hidden>)

  • Prev by Date: Calling original functions from overriding Category functions
  • Next by Date: LoginWindow and graphic daemons in the startup context
  • Previous by thread: Re: substring return a new string?
  • Next by thread: Re: substring return a new string?
  • Index(es):
    • Date
    • Thread