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: Sebastian Celis <email@hidden>
- Date: Fri, 23 Mar 2012 09:25:24 -0500
On Thu, Mar 22, 2012 at 6:39 PM, G S <email@hidden> wrote:
> On Mon, Mar 19, 2012 at 1:35 PM, Sebastian Celis
> <email@hidden>wrote:
>
>> 1) Embrace @properties...Exposing _ivars in header files is
>> gross. You never want people to access them directly, so don't make
>> those declarations public at all.
>>
>
>> 2) Technically, nothing is truly private in Objective-C, so let's stop
>> trying to completely prevent people from using private APIs.
>
> contradiction++
I think you misunderstood.
My point on (1) was that directly referencing ivars of other classes
with the -> operator is generally frowned upon in Objective-C. For
one, you miss out on KVO that way. It is generally much more accepted
to use real Objective-C methods and properties. Because of this,
putting ivars in a *public* header file is strange and just clutters
up what could otherwise be a clean, compact public interface
declaration.
My point on (2) was to just try and steer the conversation away from
where it had been headed, which was an expansive discussion on how
Objective-C handles public / protected / private methods and
properties. Yes, private methods aren't really private. I can always
use NSInvocation to call your private methods if I really want to.
What I think is much more interesting is finding the best way to
create compact, readable public header files that API consumers can
reference while still finding good ways to use both traditionally
private and protected methods in your class and subclasses. I just
want to keep those out of the public header file — not to *prevent*
you from using them, but just to communicate to you that you should
try to avoid them.
- Sebastian
_______________________________________________
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