• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Help understanding Apple's approach in documentation a little better.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help understanding Apple's approach in documentation a little better.


  • Subject: Re: Help understanding Apple's approach in documentation a little better.
  • From: Steve Christensen <email@hidden>
  • Date: Mon, 17 Aug 2015 07:35:26 -0700

On Aug 16, 2015, at 2:58 PM, Alex Zavatone <email@hidden> wrote:

> 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.

No, both the headers and docs communicate what's public and what's not; the debugger's variable panel exposes all the properties, public or not. AFAIK there's no Obj-C ivar/property/method runtime attribute that marks that item as public or private, thus the debugger has no means of determining such.

As has been mentioned previously, that useful (to you) private methods exist is an implementation detail subject to change in a future OS release. That may have been the best way to implement class functionality at the time, but since the method isn't in the public header or documentation, Apple is free to remove any or all of those private methods at any time or, more problematically, change the behavior of those methods. You can test for the former but not for the latter so you'd have to keep testing your app on every dot-release.

Think about this from your own point of view: If you released a framework for developers to use, would you leave in all of your private methods forever even if you made radical internal changes, just so that you didn't break a developer who used one of them?


_______________________________________________

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


References: 
 >Help understanding Apple's approach in documentation a little better. (From: Alex Zavatone <email@hidden>)
 >Re: Help understanding Apple's approach in documentation a little better. (From: Ken Thomases <email@hidden>)
 >Re: Help understanding Apple's approach in documentation a little better. (From: Alex Zavatone <email@hidden>)
 >Re: Help understanding Apple's approach in documentation a little better. (From: Ken Thomases <email@hidden>)
 >Re: Help understanding Apple's approach in documentation a little better. (From: Alex Zavatone <email@hidden>)

  • Prev by Date: NSViewController view not showing in NScrollView
  • Next by Date: Re: Referring to self in property initializer
  • Previous by thread: Re: Help understanding Apple's approach in documentation a little better.
  • Next by thread: NSViewController view not showing in NScrollView
  • Index(es):
    • Date
    • Thread