I am pretty new to objective-c, and I've been going over some stuff
in a book I
bought, and there is just something that is really bothering me. I
can't
really ask the author a question about his paragraph, so I thought
I'd write
here instead.
So--- This has to do with arrays, dictionaries and strings.
What I don't get is... why is there NSMutableString and NSString?
#1. It seems weird to me that a string object can't be modified
once it's
created. Why is this?
Immutable objects are useful for various reasons:
- Knowing that they can't change can help you predict your program's
behavior better. If you stashed away an immutable object in a data
structure, you know it will not have changed later on.
- Since they won't change, their storage can be optimized. For
instance the characters can be stored "in line" with the object,
rather than as a separate buffer. This would enable storing a string
with one malloc (memory allocation) block rather than two.
- Copying an immutable object can be achieved by just incrementing the
reference (retain) count of the object; there is no need to actually
create a real copy. In fact, just for this reason sometimes programs
that use string objects end up using less memory than their C-string
using counterparts.
The distinction also enables specifying the APIs better. For instance,
a vast majority of APIs that pass strings or arrays around specify the
immutable versions, meaning that the API will not change the object.
In the few cases where a mutable variant is specified, the intent is
that the receiver of the mutable object mutate the object.
#2. It seems weird that there is an alternative "mutable" object
that can be
modified. If this is the more convenient way to go, why would
anyone use a
regular NSString? Why not always just use mutable? In that case,
why does the
language even have a plain old NSString? Isn't it kind of redundant
to have
the same sort of thing but less-functional?
Sometimes the mutable object is what you use to build the data
structure in the first place. This is needed when the creation of the
object cannot be specified by the immutable creation methods alone.
Other times the mutable object is appropriate to store state that is
frequently changing; instead of always creating a new immutable copy
and discarding the previous version, you just mutate.
However, very often use of mutable objects is limited to
implementations of objects, and doesn't bleed out. So whether or not
an NSWindow's title is stored as a mutable string, when you ask for
it, NSWindow always gives you something which it claims is an NSString.
#3. For mutable objects, there is "WithCapacity".. this is where
the author
completely lost me. So he's saying that these mutable things like
NSMutableArray for example can be set to have a capacity by using
[NSMutableArray arrayWithCapacity: x]
Capacity is a hint. If you know that an object is likely to store 10
elements, the implementation can choose to optimize for that number.
But the convention is that the number is a hint, and not an absolute
limit.
... Ok.. so, if the whole point of having a mutable object is that
it has the
ability to be changed-- Why would you want to specify a capacity?
If you know
the capacity why would you be using NSMutableArray? Why wouldn't
you just use
NSArray?
A capacity of N says the object is likely to hold no more than N
elements, but it could hold any number, and it can still be mutated,
so there is a difference between a mutable object with a specified
capacity and an immutable one.
Ontop of all this, the author says that the capacity isn't a
"limit", it's ok
if you go over it--- That really made me lose it. So--- Why in the
world would
you bother setting a capacity for a container object that MIGHT have
more
objects than the number you specify???
It just seems like this stuff is so weird and unnecessary and
illogical... So,
I would love it if someone can please explain this to me. I come from
scripting languages where it's very easy to just define stuff and
use it, add
to it, remove from it, etc.. So it's really a struggle for me to
see something
that seems so fundamental to be so challenging to accomplish.
Ali
Thank you!
Patrick J. Collins
http://collinatorstudios.com
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
