This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What's the best way to use Obj-C 2.0 Properties with mutable objects, such as NSMutableArray?
Please excuse my poor English :)
In Objective C, the 'copy' qualifier doesn't retain the mutability. We have to make a property 'strong' or provide a setter ourselves.
I just want to know why the 'mutablecopy' qualifier is not provided. Any specific reason or design tradeoffs ?
Why no 'mutablecopy'?
Because making a mutable copy actually has deep and subtle meaning that makes it nontrivial. As well, you pretty much never want an objects internal storage to be externally mutable.
Also, if properties were to support mutable copy, there would need to be a version for the setter and one for the getter as each has a very different potential role (if you really did want a mutable property, you might want a mutable copying setter and normal retain getter. Or the other way around.).
None of this addresses the even nastier issue of deep versus shallow mutable copy.
Related
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How does an underscore in front of a variable in a cocoa objective-c class work?
Why rename synthesized properties in iOS with leading underscores?
I am a green hand in iOS programming.
I always see such a statement in other's code
#synthesize textNoteOrLink = _textNoteOrLink;
What is the meaning of the underline anyway? Can we just 'textNoteOrLink' in that case.
Yes you can just write textNoteOrLink.
Many developers put an underscore at the start of instance variable names (#synthesizing a property actually adds an ivar for that property) to avoid accidentally using the ivars instead of the property, bypassing setters and getters.
IMHO it's a good thing to do, but if you don't like it, just don't use it, but be cautions not to confuse properties and ivars.
This question already has answers here:
Is there any reason to declare ivars if you're using properties exclusively in Objective-C?
(4 answers)
Closed 8 years ago.
If an ivar is to be used globally within the class, but will never be accessed by other classes, are we still supposed to use properties?
It is generally a good idea, as the generated accessors will take care of things like memory management and KVO for you. You can put the property in a class extension so other classes can't use it.
For me, it depends on what the instance variable will be used for.
If it's an object representing some data, then I will always use a property.
If it's just a simple BOOL for some internal bookkeeping by a couple of methods in the class, then I won't create a property for it.
This question already has answers here:
Why shouldn't I use Objective C 2.0 accessors in init/dealloc? [closed]
(6 answers)
Closed 8 years ago.
I am aware that using setters in dealloc can create problems, if any other object is observing for changes in a property. But why should not we use them in initializers?
I have never had any problems using accessors in initializers. Maybe it depends on how much magic you have in the setters and getters – if the accessors did something too smart, you might run into trouble when using them in the initializer.
Now that I think of it, I even use the accessors in dealloc. Again, without problems. If someone is observing an object, he should make sure that the object does not get deallocated in the first place.
So, unless somebody else comes up with a compelling counter-argument, I think you might try using the accessors both in init and dealloc and see how that works for you.
The only reason not to use accessors in -init is because your object is not fully initialised and the accessor may depend on it. This is only likely to happen if you have a subclass that overrides the accessor methods.
There is a symmetrical problem on deallocation in that an overridden accessor might depend on not being called on a partially deallocated object. There is also the issue that you might send out spurious KVO notifications.
This goes to the heart of proper encapsulation. Subclasses should not need to care about the implementation details of the super class.
I have a class with a property sampleNames. It is of type NSSet. The instance variable I plan to use will be NSMutableSet.
the only reason I have for using NSMutableSet is convenience for myself. But I recall being 'told' that Mutable class should be used as sparingly as possible for some reason I cannot remember. I understand how to use both ways, so this si not so much a question about that.
What are the practical considerations when deciding whether or not to use a mutable class internally?
Please note, I am not at all interested in changing my PROPERTY to NSMutableSet. But the fact that I am using a different type internally made me think about why and I have no real justification other than convenience, Which I have found to be a bad justification by itself. Maybe it is the only reason, but i am not actively aware of what I am trading for the convenience.)
I think you are confused.
You use NSMutableSet when you need to change the contents of the set. You can only do that if it is mutable.
If you use NSSet, then you can't change the contents.
So ... your property declaration and your instance variable should be the SAME class. Either use NSSet if you don't need to change the contents or NSMutableSet if you do.
Having a different class for the property and the instance variable is a recipe for disaster ... it's not convenient and it is confusing = BAD ;-)
I have some C functions that need access Instance variables. I already pass a struct in as an argument to the function, so I added pointers to the ivars to the struct.
Is it safe to rely on the pointer remaining valid throughout the life of the app (assuming i retain and release sensibly?)
The pointer remains valid as long as the thing it points to remains valid. If the object that contains the ivars gets dealloced, and someone else is still trying to use a pointer to one of the ivars, then yeah, it'll blow up.
That said, it might be a better design to just get and set the actual values as necessary; surely the ivars aren't so big that you need to point directly to them. Doing so breaks all notion of encapsulation and requires you to do a lot more error-prone work to make sure all your object lifetimes coincide. Feel free to say more or ask another question if you want more broad design advice.