Re: Binding question
Re: Binding question
- Subject: Re: Binding question
- From: Jean-Nicolas Jolivet <email@hidden>
- Date: Tue, 28 Oct 2008 15:30:00 -0400
Thanks a lot, this was extremely helpful!
One more thing, you mentioned the term "KVO Compliance"... I understand
that this means to send the proper notifications when a change to my
property has been made...
But: would it be considered bad practice if my file class does have a
property that is used just for displaying purpose (For example, by
combining other properties (fileName, extension, size) into a nicely
formatted string) to display in a tableView... by bad practice I mean: I
know that this property is only used for display purpose and will never
be edited... but will be modified when other properties (filePath etc..)
have been modified?
Would it mean that this property is not "KVO compliant" and if so, is it
a problem? Assuming I know it should never be "observed" (i.e. it will
never be modified directly, only by modifying other properties)...
basically from your post I understand that.. technically, it's not a
problem to do it like that, but... would it be considered bad practice
since the property is not KVO compliant? and if so, is it even possible
to make it KVO compliant?
Jean-Nicolas Jolivet
Quincey Morris wrote:
On Oct 28, 2008, at 00:19, Jean-Nicolas Jolivet wrote:
Is it ok to bind my column to a property that is, in fact, not a
property but just a method that returns a string... or should I
create an actual instance variable "NSString *fileName" with a
regular getter and setter....?
A property *is* just a method (or, if readwrite, a pair of methods --
the getter and the setter). The instance variable, if there is one, is
"merely" an implementation detail within the class. Some properties
don't use an instance variable (NSString's lastPathComponent property
almost certainly doesn't, for example). Some properties (like your
"fileName") use an instance variable, but compute a value from it.
Furthermore, assuming that your File class has both filePath and
fileName properties, then your fileName implementation:
return [filePath lastPathComponent];
might alternatively be:
return [self.filePath lastPathComponent];
If you get the difference, you're home free, conceptually. (The 2nd
one extracts the file name from your filePath property, without any
assumption about how the property is implemented. The 1st one uses a
convenient instance variable that happens to contain the information
you want. Either approach is fine in this case, but in more
complicated cases, it's important to distinguish between the value of
the property and the value of some variable.)
Finally, you also need to pay attention to KVO compliance. Assuming
your filePath property is compliant (meaning that changes to it
produce the proper KVO notifications), your fileName property isn't
(unless the filePath never changes in a File object after it is
initialized, in which case the question is moot).
HTH
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden