Re: Why so many public properties all up in my grizzle?
Re: Why so many public properties all up in my grizzle?
- Subject: Re: Why so many public properties all up in my grizzle?
- From: Greg Parker <email@hidden>
- Date: Mon, 19 Mar 2012 13:39:33 -0700
On Mar 19, 2012, at 12:27 PM, Brian Lambert <email@hidden> wrote:
> Regarding this:
>
> In the chapter called "Defining a Class", not only is declaring
> an ivar in the .m file covered, but doing it in the .h file is downright
> discouraged (rightly so). In practice, this feature of Objective-C...
>
> I can't stand thus sort of subtle crap. If it's legal to declare ivars in
> the .M file and the .H file, it's crap to say it's "discouraged" in the .H
> file. Either a language is well-designed, consistent, and carefully
> thought out, or, it has turned into crap.
No, it's a flexibility vs complexity tradeoff. We could change the language to make it impossible to declare ivars in a .h file, but then you lose the ability to write higher-performance struct-like classes. Similarly, we could make it impossible to declare ivars in a .m file, but then you lose the ability to write framework classes without exposing these implementation details. Both cases are useful. One of them happens to be better in most cases, so we "discourage" the other unless you really need it.
> Is there a warning level for "You did something that's totally legal, but,
> discouraged."?
There are warnings of this form. For example, if you perform an assignment inside an `if` condition, the compiler will warn about it on the assumption that you probably meant to perform a comparison instead. The problem with this sort of warning is that there needs to be a clean way to say "no really, do the discouraged thing" to pacify the compiler.
> I love Objective-C Category files because they
> allow me to segment my implementation such that each file more or less
> represents each interface that my class implements
We like this too; it's commonly used inside system frameworks for large classes like NSWindow. In a recent version of Xcode we added optimizations to the linker so that there's no longer any extra runtime overhead if you write categories on your own classes in the same binary.
> Is there a way to declare ivars in the .M file AND have them accessible
> from Objective-C Category files for the class?
You can keep ivars out of your public .h file and use them in categories. First, declare the ivars as @package in a class extension in another header file. Then #include that header file in your class implementation and your category implementations.
// MyClass.h
@interface MyClass : SomeSuperclass {
// look ma, no ivars
}
@end
// MyClass-Internal.h
#import "MyClass.h"
@interface MyClass () { // class extension
@package
int anIvar;
}
@end
// MyClass.m
#import "MyClass-Internal.h"
@implementation MyClass
...
@end
// MyClass-Category.m
#import "MyClass-Internal.h"
@implementation MyClass (Category)
-(int)method { return anIvar; }
@end
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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