tag:blogger.com,1999:blog-34442452.post2863370892341619067..comments2023-04-16T03:49:21.961-07:00Comments on Cocoa Samurai: Cover up those ivarsColin Wheelerhttp://www.blogger.com/profile/16010768305821496589noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-34442452.post-41655783598304412432013-05-05T17:21:44.881-07:002013-05-05T17:21:44.881-07:00"Hmm, even though I be able to force outer wo..."Hmm, even though I be able to force outer world to use only getter, there actually exists a matching setter, right? (Because the class extension redeclared a property to be readwrite-able.)<br /><br />Then how can I keep outer world from accessing the setter by using performSelector:withObject: with the selector of it?<br /><br />Well, just a quick question."<br /><br />Actually it is Colin Wheelerhttps://www.blogger.com/profile/16010768305821496589noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-4482685919658016432013-05-04T04:53:06.593-07:002013-05-04T04:53:06.593-07:00Hmm, even though I be able to force outer world to...Hmm, even though I be able to force outer world to use only getter, there actually exists a matching setter, right? (Because the class extension redeclared a property to be readwrite-able.)<br /><br />Then how can I keep outer world from accessing the setter by using performSelector:withObject: with the selector of it?<br /><br />Well, just a quick question.Ardiehttps://alpha.app.net/ardiefoxnoreply@blogger.comtag:blogger.com,1999:blog-34442452.post-56042320130523705022012-12-27T14:21:49.723-08:002012-12-27T14:21:49.723-08:00Ramy yes I am aware of it, however you are missing...Ramy yes I am aware of it, however you are missing the point. You shouldn't even see stuff that is private in the header as Objective-C stands at the moment.Colin Wheelerhttps://www.blogger.com/profile/16010768305821496589noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-45893969334823479492012-12-23T16:30:48.800-08:002012-12-23T16:30:48.800-08:00Are you all avare of the @private directive, right...Are you all avare of the @private directive, right?Anonymoushttps://www.blogger.com/profile/01850352222284888843noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-21409938889848986462012-08-31T09:27:10.342-07:002012-08-31T09:27:10.342-07:00Konstantin,
I never explicitly declare my ivars. ...Konstantin,<br /><br />I never explicitly declare my ivars. I simply put the property in my class extension, and let the property auto create them for me.<br /><br />Partially this is to avoid possible bugs, mentioned in my previous comment. However, mostly it's just to avoid the extra typing.<br /><br /> I will, however, explicitly declare private methods in the class extension. At one pointRichhttps://www.blogger.com/profile/04243458955367448042noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-23269250165766307532012-08-31T09:17:05.374-07:002012-08-31T09:17:05.374-07:00@Ardie This will not cause a setter to be generate...@Ardie This will not cause a setter to be generated, unlike Colin's example of redefining the @property as read-write in a class extension. The @synthesize adds nothing since it's no longer necessary and a _dbo ivar would have been generated anyway in your example, even if you omit the @synthesize. If you don't mind direct ivar access, then this will work, but in general, I prefer Érichttps://www.blogger.com/profile/03051181927496206408noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-8716345097889258362012-08-31T08:22:30.092-07:002012-08-31T08:22:30.092-07:00How about the following way of manipulating read-o...How about the following way of manipulating read-only properties inside the implementation?<br /><br />// asdf.h<br />@interface asdf<br />@property(readonly, nonatomic) sqlite3 *dbo;<br />...<br />@end<br /><br />// asdf.m<br /><br />@implementation asdf<br />@synthesize dbo=_dbo; // _dbo is writable.<br />...<br />@endArdienoreply@blogger.comtag:blogger.com,1999:blog-34442452.post-90754189161773545342012-08-31T05:49:55.304-07:002012-08-31T05:49:55.304-07:00Oh, and yes, I also do use the "MyBaseClass+P...Oh, and yes, I also do use the "MyBaseClass+Protected.h" headers from time to time to expose "protected" members (ivars/properties and methods) to subclasses only.Érichttps://www.blogger.com/profile/03051181927496206408noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-60458705125374699502012-08-31T05:47:22.024-07:002012-08-31T05:47:22.024-07:00@Mark I think your last point was actually aimed a...@Mark I think your last point was actually aimed at Konstantin. :-) Regardless, I agree with you -- I don't tend to use class extensions as I used to (because of the point I just made in the previous comment), but when I do find a need to declare a private ivar, then I agree with you that I prefer to put it in a class extension (i.e. in a @interface) at the top of the .m file, rather than theÉrichttps://www.blogger.com/profile/03051181927496206408noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-25149481842273372782012-08-31T05:38:25.442-07:002012-08-31T05:38:25.442-07:00@lowell - the auto-synthesize is new in Xcode 4.4....@lowell - the auto-synthesize is new in Xcode 4.4. No need to explicitly do @synthesize blah = _blah any more.<br /><br />@Eric - I can't speak for Colin, but I usually put any explicit ivars in the class extension. In my source files it's in a pretty stable location (right after the headers), while the implementation tends to float around (I might have a batch of constants, or helper Mark Dalrymplehttp://borkware.comnoreply@blogger.comtag:blogger.com,1999:blog-34442452.post-84741489651483431602012-08-31T05:33:04.282-07:002012-08-31T05:33:04.282-07:00Also, starting with LLVM compiler 4.0, it's no...Also, starting with LLVM compiler 4.0, it's no longer necessary to declare "private" methods in a class extension in the .m file. There is no longer a need to forward-declare methods before invoking them inside a class implementation. If the method exists, the compiler will find it, regardless of where it appears in the implementation file (and will dutifully complain if the method Érichttps://www.blogger.com/profile/03051181927496206408noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-50965177422016996842012-08-31T05:26:00.490-07:002012-08-31T05:26:00.490-07:00What is in your opinion the better practice - to w...What is in your opinion the better practice - to write ivars in the @implementation or in the class extension part? Till today I had them all in the class extension, so that both ivars and private properties are in the same placeKonstantinhttps://www.blogger.com/profile/05582569902006400171noreply@blogger.comtag:blogger.com,1999:blog-34442452.post-40004181624682857352012-08-30T23:02:49.486-07:002012-08-30T23:02:49.486-07:00This isn't new, it's been around since Xco...This isn't new, it's been around since Xcode 4.2.lowellnoreply@blogger.comtag:blogger.com,1999:blog-34442452.post-56415987362236731332012-08-30T20:23:32.769-07:002012-08-30T20:23:32.769-07:00I totally agree with you. Hide the implementation ...I totally agree with you. Hide the implementation details. Of course, in Objective-C nothing is ever really hidden--but the goal is to clearly communicate the public API with other developers (including your future self).<br /><br />Actually, I try to avoid explicitly declaring ivars at all. In modern Objective-C this can lead to a bug, if the name given in @synthesize (or implicit @synthesize Richhttps://www.blogger.com/profile/04243458955367448042noreply@blogger.com