On Oct 17, 2008, at 12:25 PM, Ignacio Enriquez wrote:
Thanks for your responses.
You're welcome.
First: self.property is only or reading right?
No. self.property may be used either to get the value of the property
or, as the target of an assignment statement, to set the value of the
property:
foo = self.property; // gets the property value, equivalent to foo =
[self property]
self.property = foo; // sets the property value, equivalent to [self
setProperty:foo]
In my earlier response I was responding to your examples, which were
all of the get-the-value form.
this also means that
for setting the value I should only use property (and not
self.property ?)
No. When getting the value, the choice to use direct instance
variable access vs. the dot syntax (which implicitly calls the getter
method) depends on a couple of factors: does the getter have side
effects? Do you want those side effects to happen for a given access
to the property?
When setting the value it is almost always the case that you want to
use the setter method, because the setter is likely to do memory
management. Also, setters are more likely than getters to have
important side effects like KVO change notifications. So, you should
either use the dot syntax (self.property = foo) or an explicit call to
the setter method ([self setProperty:foo]). Which you use is a matter
of personal style. Most would probably find the dot syntax to be
cleaner.
Does this applies also for "retain" attribute?
Retaining is part of the memory management done by the setter, and
therefore one of the reasons it's important to use the setter (either
implicitly through dot syntax or explicitly).
In first place I wrote a simple class , but the fact is that I wrote a
singletton inside my program .
and all of my properties are "nonatomic, retain"
why nonatomic?? -> nonatomic is faster than the default atomic
why retain? -> I thought that retaining every property I would not
have problems with object life (retainCount etc... )(but I might be
wrong about this because of my crashes)
There's no way to come up with a rule that you can apply blindly to
avoid actually thinking about and understanding the issues. You
always have to understand why you're doing what you're doing.
Yes, "retain" is almost always more appropriate than "assign" when
dealing with object properties. However, the "almost" is important.
As others have been saying, use "copy" when the property represents an
attribute of the class rather than a relationship between objects.
Use "retain" for relationships, _except_ when it's necessary to use
"assign" to avoid retain cycles (for example, in a tree structure,
parents should retain children, but children shouldn't retain their
parents).
Well the thing is : I didn't write
self.property = myValue
but only
property = myValue;
in 99% of the cases.
That's a mistake. You are bypassing the setter. So, this isn't
performing correct memory management. Also, the changes aren't being
properly broadcast to observers via KVO. (There are rare cases when
you want to deliberately avoid KVO change notifications, but you
should get the general case right before considering the exceptions.)
and when I wanted to refer (or use) this class instance's properties
from another class, it results that there is nothing so the app
crashes. In others words is like the object is not longer living any
more.
then I added "self." before every property and worked fine. But I
don't know the reason.
Not my program is getting bigger and bigger and having more often
problem with this.
I would like to know if there is a general rule about properties
usage,
for example
when to use retain? when to use assign? when to use copy?
when you use "retain" use "self.property" for... because ...and use
only "property" for... because....
when you use "assign" use "self.property" for...because ... and use
only "property" for ... because...
(same for "copy", "self.property" and "property")
Does any one knows this gold rule? ; )
I'm starting to think that you should avoid declared properties and
dot syntax for now. With some of the newer features of Objective-C
and Cocoa, it can be helpful for novices to first become proficient
with the "old way" so they understand the details which are hidden by
the "new way".
In other words, perhaps you should get comfortable writing your own
accessors instead of letting Objective-C synthesize them for you. And
you should explicitly invoke them throughout your code, rather than
blindly coding without understanding what's happening (with dot
syntax, for example).
You definitely need to review the Objective-C basics, the Cocoa
fundamentals, and the Cocoa memory management guidelines.
Regards,
Ken
_______________________________________________
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 [EMAIL PROTECTED]
