On Jun 3, 2015, at 12:46 PM, Mark Wright wrote: > This is important and is all about *scope*. > > A class’s properties are only public if they’re in the header.
Exactly. With that said, why do we not have a convention with properties declared within the .m file for showing that they are private but not ivars? If we do, what is it? If we don't, let's think about this and submit a well thought out standard for this and let the list suss it out, then we start using it. Currently, I know of no convention that is in common use for this and Xcode's code coloring doesn't help us to see the differences between: public properties private ivars that back public properties private properties private ivars that back private properties Am I missing anything here? As food for thought, back in late last century, we had this wonderful multimedia tool known as Macromedia Director and a very LUA/Hypertalk/Smalltalk language in it called Lingo. Within this tokenized, object oriented scripting language, we have properties that were scoped to the script(class) they were created in, globals and locals. Parameters also mattered too, because you would have to tell the difference between them and locals. That's it. We took the approach of naming each global starting with a lowercase g, like gSoundManager. Likewise, properties always started with a lowercase p, like pSoundChannel. Within functions, I wanted to see the difference between my passed in parameters and my locals. To show that difference, each local started with a lowercase my, as in myCurrentSoundChannel. This approach made determining every variable's scope really, really, really a no brainer. Simply by eveballing each variable, I wouldn't have to waste more than one brain cell cycle to determine out what its scope was and what it applied to and where it could be used. It ended up being REALLY NICE, because you could just look at the code and "get" a lot of how and where the data structures applied to the program they were in. The idea was "you didn't have to think to determine the variable's purpose and area of affect(scope)". I don't know about the seasoned Objective-C veterans, but I'd sure love to see some standard approaches like that here in Objective-C. Sooo, anyone have any good suggestions to get us there? Anyone? Anyone? Bueller? Anyone? _______________________________________________ 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
