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:45:05 -0700
One final note:
ivars in the .H file of a public framework is *obviously stupid* as it
leaks implementation details.
ivars in the .H file of my Foo class, which no one other than me will ever
use, should be relatively OK. After all, I'm not trying to prevent myself
from knowing anything about my implementation of Foo. I'm just trying to
ensure that my *intent* for my class is well-understood to other
programmers who will work on Foo in the future.
On Mon, Mar 19, 2012 at 12:27 PM, Brian Lambert <email@hidden>wrote:
> 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