Re: NSMutableArray morphs itself into an NSArray?
Re: NSMutableArray morphs itself into an NSArray?
- Subject: Re: NSMutableArray morphs itself into an NSArray?
- From: Shawn Erickson <email@hidden>
- Date: Mon, 8 Mar 2004 19:55:26 -0800
On Mar 8, 2004, at 7:16 PM, Jerry Krinock wrote:
After reading the great discussion on alloc/init vs.
convenience/retain, I
went back to my code and I think maybe I found the problem, getting
back to
my original question of: Can an NSMutableArray morph itself into an
NSArray?
The first time I use this NSArray, I do this:
crontabLines = (NSMutableArray*)[aString componentsSeparatedByString:
@"\n"];
I think this was might be the cause of the problem. The NSString
method
-componentsSeparatedByString "returns an NSArray*". My typecasting
does not
change the type, since Objective-C objects "know their own type" and
will
not be swayed by my typecasting.
This is correct. Casting cannot change the class of an object (the code
define in the methods). Additionally casts are only a compile time
construct in Objective-C (at least for objects) they do not exist at
runtime. At run time you can send any message to any object of course
the target object may not support the message or like receiving it.
Later in the program, I call a mutating method on crontabLines:
[crontabLines removeAllObjects] ;
and it raises the exception:
*** -[NSCFArray removeAllObjects]: mutating method sent to immutable
object
This would be expected given it being an NSArray and the error states
the issue.
So, I'd like your expert opinions on this:
1) Have I properly explained how the NSMutableArray morphed into an
NSArray?
Yes... in that it never was a NsMutableArray to begin with.
2) Why is it that this exception gets raised on my user's computer,
but not
on my computer. We're both running 10.3.2. And supposedly, thousands
of
users are running this program, I've got all 5-star ratings on
VersionTracker, and this is the only guy that's triggered the problem!
Hard to say without looking at the code. Based on the below it sounds
like you are somehow creating a mutable array and setting crontabLines
to point at it. Then later on you potentially replace that reference
with one that points to the one generated by
componentsSeparatedByString.
Another potential source of this is that NSArray and NSMutableArray are
implemented as a class cluster. So you are not really working with an
instance of NSArray or NSMutableArray but some sub-class. Today likely
CFArray for both NSArray and NSMutableArray so depending on usage
pattern the target object may actually support mutating messages yet
you really shouldn't be sending them... however since you see the
exception I would assume something more like to former as the source.
One final source could be an optimization down in
componentsSeparatedByString that returns a mutable array or an
immutable one depending on some situation in the data it is working on.
The method can return any type of object it wants as long as it is at
least a NSArray (or any sub-class).
3) To fix the problem, I replaced the bad line with this:
[crontabLines setArray:[aString componentsSeparatedByString: @"\n"]];
I assume you created a mutable array instance an set crontabLines to
reference it? If so then setArray is copying references to the items
from the one array into you mutable array.
You could also use mutableCopy to change a immutable object into a
mutable one.
-Shawn
_______________________________________________
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.