Re: Help understanding Apple's approach in documentation a little better.
Re: Help understanding Apple's approach in documentation a little better.
- Subject: Re: Help understanding Apple's approach in documentation a little better.
- From: Alex Zavatone <email@hidden>
- Date: Sun, 16 Aug 2015 17:58:33 -0400
On Aug 16, 2015, at 5:35 PM, Ken Thomases wrote:
> On Aug 16, 2015, at 4:18 PM, Alex Zavatone <email@hidden> wrote:
>
>> On Aug 16, 2015, at 4:49 PM, Ken Thomases wrote:
>>
>>> On Aug 16, 2015, at 3:09 PM, Alex Zavatone <email@hidden> wrote:
>>>
>>>> Why isn't it in Apple's documentation for storyboards?
>>>
>>> Because these are private implementation details. They are subject to change without notice. You can't rely on them in any shipping code.
>>
>> If they were private shouldn't there be a naming convention that states they are private?
>
> No, there's no naming convention for properties to indicate they are private.
>
>> If I look at an instance of a storyboard object in the Variables View in the Debugger, I can expand the object and they are all listed.
>
> And? You've already shown they are visible in the runtime's information about the class. It's not surprising that the debugger also has access to this information.
>
>> Is there some sort of naming or visual convention that communicates "you might be see these, but they're private and not for you to mess with"?
>
> No.
>
>> As soon as I saw them exposed by the runtime tool, and I saw that expanding the storyboard instance exposed them, I thought that the docs and header files were hiding information that was accessible.
>
> They are "accessible" through these (and probably other) mechanisms, but that doesn't mean they are _appropriate_ to access. Working with the frameworks or a library is always subject to a design contract. There are plenty of times when it's _possible_ to do something but, if the design contract doesn't specifically allow it, it's disallowed. Accessing private properties is just a particular case of this general rule.
>
>> Is there anything that shows that they are private?
>
> Their non-presence in the documentation and headers.
Would be REALLY nice if there was something visual that simply communicated to you that they are not for public consumption.
If I see it in the left pane of the debugger, and no visual indicators are stating that it's restricted, It's telling us that it's available - unless we spend the time to look up the internals for everything that's displayed in the variables pane that exposes an object instanced from a framework class.
I know it's too simplistic to assume that a color change would be enough and appropriate to indicate to the programmer that "you can see there, but you really don't have access to them", but SOME sort of treatment to the private data would be really nice when displaying it, so that it's painfully obvious to the developer that it's private freaking data.
The developer should just have to look and instantly see that it's data that's used behind the scenes and they can't play with it.
If the debugger's variable pane exposes it, it's misleading if it doesn't somehow indicate that it's not for the developer to access.
At the least, it's confusing, because the docs say it's not supposed to be there, yet there it is.
Fun.
Thanks, Ken. Dearly appreciated.
- Alex Zavatone
_______________________________________________
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