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: Brian Lambert <email@hidden>
- Date: Mon, 19 Mar 2012 12:27:26 -0700
I'd like an argument, please.
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.
Is there a warning level for "You did something that's totally legal, but,
discouraged."?
ivars in the .H file are totally necessary in order to use ivars with
Objective-C Category files. 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, vs, loading *all* the
implementation details into one .M file simply so I don't have to declare
ivars in the .H file.
I get why ivars in the .H file is not super fantastic, so let's not have
that debate.
Is there a way to declare ivars in the .M file AND have them accessible
from Objective-C Category files for the class?
Thanks!
Brian
On Mon, Mar 19, 2012 at 11:32 AM, Matt Neuburg <email@hidden> wrote:
> On Fri, 16 Mar 2012 17:11:24 -0400, Marco Tabini <email@hidden> said:
> >> That time has passed now, so you can now completely specify IBOutlets
> (and IBActions) in your implementation file and hide the details from the
> outside world. If you want properties, you can use a class extension like
> so to add them:
> >
> >Sorry to hijack this conversation, but I've been meaning to ask: Where is
> this documented? I stumbled on this feature (and the ability to declare
> ivars directly in the .m file), but I didn't see it explained it anywhere.
> I'm sure I'm just not looking in the right place, but I can't find it
> anywhere.
>
> See Apple's document "The Objective-C Programming Language".
>
> 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 did not swim into
> most people's ken until Xcode 4.2, when LLVM because the default compiler.
>
> In the chapter called "Categories and Extensions", declaration of private
> properties is discussed. That feature is considerably older.
>
> m.
>
> PS And of course there's also my book, which makes much of these features.
>
> PPS The trouble with language improvements like this, and with documents
> like The Objective-C Programming Language, is that there's a terminus point
> somewhere and they don't tell you exactly when it is. What I mean is, you
> can surprise yourself by adopting an improvement of this sort and then
> opening your project in an earlier version of Xcode that doesn't understand
> it. Also, different *parts* of Xcode may not understand it; for example,
> your code will compile, but the feature where you can drag from an ivar to
> the nib editor to form an outlet might not work (though now, I believe, it
> does).
>
> --
> matt neuburg, phd = email@hidden, <http://www.apeth.net/matt/>
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
> _______________________________________________
>
> 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