Re: substring return a new string?
Re: substring return a new string?
- Subject: Re: substring return a new string?
- From: Ondra Cada <email@hidden>
- Date: Thu, 18 Mar 2004 22:01:46 +0100
Marco,
On Thursday, Mar 18, 2004, at 21:34 Europe/Prague, Marco Scheurer wrote:
There is a problem: how am I supposed to know the implementation
detail that this a generated on the fly value and not a cached value
of NSFileManager?
Since it is documented so, of course. Well it is not for NSFileManager
(which I've used just to point out that not anything returned must be a
property), but it definitely is for the class in question:
===
On Thursday, Mar 18, 2004, at 14:05 Europe/Prague, Ondra Cada wrote:
Nevertheless, if the speed/space are very important and this approach
seems wrong, 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
===
In other words, how am I supposed to know that changing it will not
change the state of NSFileManager? Just because you decided to
advertise it as returning NSMutableArray?
No. Just because I documented it so.
This would be a really weird convention, and frankly I've never seen
anything like that.
It's not a convention, it's (so far as I can say) the best solution in
case (a) the return value is generated on the fly (given by the
principle of the task) (b) and cannot be reasonably cached, and (c)
efficiency is too important to make&return an immutable copy.
Of course, there still is the possibility to use "your solution" to
return a mutable object advertised as an immutable one. Again, *in case
the efficiency is important*, the possibility the user can exploit the
fact the object is not shared and is already mutable (given by "my"
solution) seems to me more important than the possibility to change the
implementation in future say to cache (given by "your" solution). That
is, at least generally, until we are speaking a concrete case.
---
Ondra Hada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
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.