On Aug 16, 2015, at 2:58 PM, Alex Zavatone <z...@mac.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
