Re: Obj-C - your thoughts on hiding data members?

[Clark S. Cox III]

> On Jan 28, 2016, at 03:14, Dave  wrote:
> 
> 
>> On 28 Jan 2016, at 00:34, Alex Zavatone  wrote:
>> 
>> Ahh, just a little testing shows that well, if it’s not ASCII, it’s not 
>> going to work, period.  
> 
> See? If it ain’t ASCII it ain’t Source Code! lol

But that was originally said in response to Unicode in *comments*, not in 
identifiers.

> 
> Dave
> 
> ___
> 
> 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/clarkcox3%40gmail.com
> 
> This email sent to clarkc...@gmail.com


___

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

Re: Obj-C - your thoughts on hiding data members?

[Dave]

> On 28 Jan 2016, at 00:34, Alex Zavatone  wrote:
> 
> Ahh, just a little testing shows that well, if it’s not ASCII, it’s not going 
> to work, period.  

See? If it ain’t ASCII it ain’t Source Code! lol

Dave

___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

Apparently you can't in obj-c, but there appear to be a few tricks on the Swift 
side of things that are interesting and worth checking out.  I saw examples of 
using option p as the pi character and using it in an assignment statement.  
But this is objective-c so you're 100% right.

Sent from my iPhone

> On Jan 28, 2016, at 6:14 AM, Dave  wrote:
> 
> 
>> On 28 Jan 2016, at 00:34, Alex Zavatone  wrote:
>> 
>> Ahh, just a little testing shows that well, if it’s not ASCII, it’s not 
>> going to work, period.  
> 
> See? If it ain’t ASCII it ain’t Source Code! lol
> 
> Dave
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com

___

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

Re: Obj-C - your thoughts on hiding data members?

[Uli Kusterer]

On 27 Jan 2016, at 12:30, Dave  wrote:
> I find the “_” very difficult to see and also I tend to think of it as “Apple 
> Reserved”, which I think it used to be?

Still is, for *methods* so for selectors/properties. However, a single 
underscore is fine for instance variables backing a method, and in fact is the 
default when auto-synthesizing. And it's also not in violation of the C 
standard's rules about underscored and double-underscored identifiers (see e.g. 
here for a good summary of those 
http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier).

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://stacksmith.org





___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 27, 2016, at 2:49 PM, Alex Zavatone  wrote:

> 
> On Jan 27, 2016, at 6:38 AM, Dave wrote:
> 
>> 
 
> I'm going to step out on a limb and since Xcode has supported editing in 
> UTF-8 and 16, that we look into those character sets and pick some 
> symbols that accurately represent public, protected and private.
 
 Now you’re pulling our legs, right Alex?
>>> 
>>> Yeah, I know.  It's really non conventional, buuut… I've started using some 
>>> of the characters such as the block and non breaking line to make better 
>>> formatting for comments and logging.
>> 
>> Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back 
>> to bite you! 
> 
> Wise words.  
> 
> I base this attempt on a fair amount of crash test dummies who have risked 
> this before me and constantly asking questions.  Is the character set 
> supported by Xcode?  By Git?
> 
> The popups in the right side of Inspector Panel with a setting for Text 
> Encoding and the amount of people who I've seen code in Japanese with the 
> UTF-16 encoding justified me asking this.
> 
> But for those crazy Swift kids who are using smilies in variable names, I'm 
> going to let them drive the crash test vehicle. 
> 
>>> Other people who are on the Swift side of things are even using smilies and 
>>> emoticons in their code.  Or so they claim.  That scares me.
>> 
>> I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol

Ahh, just a little testing shows that well, if it’s not ASCII, it’s not going 
to work, period.  

“Non-ASCII characters are not allowed outside of literals and identifiers"

They do work fine for logging and in comments though.

myConfigurableOption = @"███"; //  ◄ ⬅︎

someSillyString = @"⎯⎯";


___

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

Re: Obj-C - your thoughts on hiding data members?

[Clark S. Cox III]

> On Jan 27, 2016, at 03:38, Dave  wrote:
> 
> 
>>> 
 I'm going to step out on a limb and since Xcode has supported editing in 
 UTF-8 and 16, that we look into those character sets and pick some symbols 
 that accurately represent public, protected and private.
>>> 
>>> Now you’re pulling our legs, right Alex?
>> 
>> Yeah, I know.  It's really non conventional, buuut… I've started using some 
>> of the characters such as the block and non breaking line to make better 
>> formatting for comments and logging.
> 
> Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back 
> to bite you! 
> 
>> Other people who are on the Swift side of things are even using smilies and 
>> emoticons in their code.  Or so they claim.  That scares me.
> 
> I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol

That's awfully America-centric of you :)
___

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

Re: Obj-C - your thoughts on hiding data members?

[Carl Hoefs]

> On Jan 27, 2016, at 4:38 AM, Dave  wrote:
> 
>>> 
 I'm going to step out on a limb and since Xcode has supported editing in 
 UTF-8 and 16, that we look into those character sets and pick some symbols 
 that accurately represent public, protected and private.
>>> 
>>> Now you’re pulling our legs, right Alex?
>> 
>> Yeah, I know.  It's really non conventional, buuut… I've started using some 
>> of the characters such as the block and non breaking line to make better 
>> formatting for comments and logging.
> 
> Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back 
> to bite you! 
> 
>> Other people who are on the Swift side of things are even using smilies and 
>> emoticons in their code.  Or so they claim.  That scares me.
> 
> I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol

If I can't make a punched card deck out of it, it ain't REAL source code.

-Carl


___

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

Re: Obj-C - your thoughts on hiding data members?

[Raglan T. Tiger]

> On Jan 27, 2016, at 11:49 AM, Carl Hoefs  
> wrote:
> 
> If I can't make a punched card deck out of it, it ain't REAL source code.

Would that be punched on 80 or 96 column cards ?

-rags

___

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

Re: Obj-C - your thoughts on hiding data members?

[Rick Mann]

> On Jan 27, 2016, at 03:30 , Dave  wrote:
> 
>> I would strongly urge that anyone prefixing ivars use this convention, for 
>> consistency. Additionally, I find that the underscore adds less visual 
>> clutter than a letter like “m”. Your brain doesn’t see it as a letter, so it 
>> doesn’t get in the way of reading the variable name.
> 
> I find the “_” very difficult to see and also I tend to think of it as “Apple 
> Reserved”, which I think it used to be?

I agree; I find the underscore very visually distracting, as it looks like an 
operator, not part of a word. It's a visceral reaction that makes me hate the 
Apple convention.

-- 
Rick Mann
rm...@latencyzero.com



___

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

Re: Obj-C - your thoughts on hiding data members?

[Clark S. Cox III]

> On Jan 27, 2016, at 11:49, Alex Zavatone  wrote:
> 
> 
> On Jan 27, 2016, at 6:38 AM, Dave wrote:
> 
>> 
 
> I'm going to step out on a limb and since Xcode has supported editing in 
> UTF-8 and 16, that we look into those character sets and pick some 
> symbols that accurately represent public, protected and private.
 
 Now you’re pulling our legs, right Alex?
>>> 
>>> Yeah, I know.  It's really non conventional, buuut… I've started using some 
>>> of the characters such as the block and non breaking line to make better 
>>> formatting for comments and logging.
>> 
>> Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back 
>> to bite you! 
> 
> Wise words.  
> 
> I base this attempt on a fair amount of crash test dummies who have risked 
> this before me and constantly asking questions.  Is the character set 
> supported by Xcode?  By Git?

Both support UTF-8. Full stop.

> The popups in the right side of Inspector Panel with a setting for Text 
> Encoding and the amount of people who I've seen code in Japanese with the 
> UTF-16 encoding justified me asking this.

Just stick to UTF-8 and you'll be fine.
UTF-16 is a silly encoding to use for source code :)

> 
> But for those crazy Swift kids who are using smilies in variable names, I'm 
> going to let them drive the crash test vehicle. 
> 
>>> Other people who are on the Swift side of things are even using smilies and 
>>> emoticons in their code.  Or so they claim.  That scares me.
>> 
>> I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol
>> 
>> All the Best
>> Dave
> 
> 
> ___
> 
> 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/clarkcox3%40gmail.com
> 
> This email sent to clarkc...@gmail.com


___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 27, 2016, at 6:38 AM, Dave wrote:

> 
>>> 
 I'm going to step out on a limb and since Xcode has supported editing in 
 UTF-8 and 16, that we look into those character sets and pick some symbols 
 that accurately represent public, protected and private.
>>> 
>>> Now you’re pulling our legs, right Alex?
>> 
>> Yeah, I know.  It's really non conventional, buuut… I've started using some 
>> of the characters such as the block and non breaking line to make better 
>> formatting for comments and logging.
> 
> Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back 
> to bite you! 

Wise words.  

I base this attempt on a fair amount of crash test dummies who have risked this 
before me and constantly asking questions.  Is the character set supported by 
Xcode?  By Git?

The popups in the right side of Inspector Panel with a setting for Text 
Encoding and the amount of people who I've seen code in Japanese with the 
UTF-16 encoding justified me asking this.

But for those crazy Swift kids who are using smilies in variable names, I'm 
going to let them drive the crash test vehicle. 

>> Other people who are on the Swift side of things are even using smilies and 
>> emoticons in their code.  Or so they claim.  That scares me.
> 
> I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol
> 
> All the Best
> Dave


___

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

Re: Obj-C - your thoughts on hiding data members?

[Dave]

>> 
>>> I'm going to step out on a limb and since Xcode has supported editing in 
>>> UTF-8 and 16, that we look into those character sets and pick some symbols 
>>> that accurately represent public, protected and private.
>> 
>> Now you’re pulling our legs, right Alex?
> 
> Yeah, I know.  It's really non conventional, buuut… I've started using some 
> of the characters such as the block and non breaking line to make better 
> formatting for comments and logging.

Wow Man, you *do* like living on the wild-side. I hope it doesn’t come back to 
bite you! 

>  Other people who are on the Swift side of things are even using smilies and 
> emoticons in their code.  Or so they claim.  That scares me.

I’m more of a if its not in the ASCII set it ain’t Source Code brigade! lol

All the Best
Dave

___

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

Re: Obj-C - your thoughts on hiding data members?

[Dave]

> On 26 Jan 2016, at 19:10, Jens Alfke  wrote:
> 
> 
>> On Jan 26, 2016, at 6:32 AM, Alex Zavatone > > wrote:
>> 
>> Since we're all computery and programmy and stuff, couldn't we put together 
>> a little matrix of the type of variable and come up with several loose 
>> standards?
>> The reason I ask this (am pressing on this) is that a large amount of what 
>> communicates to the programmer is in the naming and casing convention of the 
>> words used. 
> 
> There is a very longstanding convention in Objective-C — going back to the 
> NeXT days — to prefix instance variables with underscores. You’ll see that in 
> many of Apple’s headers (the ones that still list ivars in the @interface) 
> and in some Apple sample code.
> 
> (There was a time when Apple was warning 3rd party developers not to do this 
> because of name collisions with inherited ivar names, but that’s a non-issue 
> with the modern Obj-C runtime.)
> 
> I would strongly urge that anyone prefixing ivars use this convention, for 
> consistency. Additionally, I find that the underscore adds less visual 
> clutter than a letter like “m”. Your brain doesn’t see it as a letter, so it 
> doesn’t get in the way of reading the variable name.

I find the “_” very difficult to see and also I tend to think of it as “Apple 
Reserved”, which I think it used to be?

> Beyond that it’s a matter of preference. I prefix static variables with “s”, 
> a convention that dates back to MacApp (~1988!). I don’t see any reason to 
> prefix function parameters or locals in general, since they’re the default, 
> although I sometimes use an “out” prefix for a by-reference parameter like an 
> NSError**.

I find it much better to differentiate between, Entry Parameters, Local 
Variables, Ivar’s and Properties. I also use “g” for global instead of “s”.

I’ve had to debug a lot of code written by other people and finding that a 
local name overrides an iVar after a few hours trying to figure out what its 
trying to do made me this way!

Cheers
Dave

___

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

Re: Obj-C - your thoughts on hiding data members?

[Dave]

> I'd suggest it's not necessary. What I like about member naming conventions 
> has to do with identifying their scope. In my personal programming style, I 
> name things with a single lower-case letter to make their scope known; that 
> makes it much easier to track down a variable and understand its use (more 
> useful than type, which is generally obvious and not actually the important 
> in context, and which can change over time). I'd suggest that accessibility 
> of a symbol is not all that important when looking at the code, either.
> 
> FWIW, my convention comes from PowerPlant days (and hence, C++):
> 
> • Local variables start with a lower-case letter. Local variables are 
> declared as close the point of first use as possible.
> • Parameters start with "in", "out", or "inout", depending on their intended 
> use.
> • Member variables (ivars) start with a lower-case "m" (rather than an 
> underscore). Their corresponding property names delete the prefix character 
> and start with a lower-case letter.
> • Static member variables (which don't really exist in Obj-C, but which I 
> implement as file-scope variables) are prefixed with "s".
> • Constant variables, either via "const" keyword or #define, are camel-case 
> and prefixed with "k"
> • Preprocessor flag are camel-case and prefixed with "q".
> • Preprocessor macros are treated like free functions (camel-case), and 
> implemented as inline functions whenever possible.
> 
> Knowing the *scope* of a variable in unfamiliar or long-forgotten code, I 
> find, helps me understand what's going on more than any other piece of 
> information.

Definitely, 100% agree, also once you have implemented a fair amount of code in 
a project that follow your conventions, you find Programming Patterns begin to 
emerge and common pieces of code stand out and make refactoring much easier. 

Cheers
Dave



___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 5:47 AM, Dave wrote:

> Hi,
> 
>> Yeah, the ivar for an @property called myThing is _myThing and we can know 
>> that by looking at it with our eyeballs.  How do we extend that type of 
>> visual exposure of information of the “thing” being inspected in a similar 
>> manner?
>> 
>> Do we have any standards for this?  
>> 
>> If not, should we create some?
> 
> There are no standards AFAIK and you will never get everybody to agree a 
> “standard” naming convention, I have my own scheme though:
> 
> Entry Parameters to Methods are prefixed the “the”, local Variables are 
> prefixed “my”, properties are prefixed “p”, Ivar’s “m”, constants “k” and I 
> always try to give some clue as to the type of the data in the variables, 
> e.g. myNameDict, myAddresssAddress, etc.
> 
> Cheers
> Dave

I'm a big fan of using my in front of local variables as well.

Since we're all computery and programmy and stuff, couldn't we put together a 
little matrix of the type of variable and come up with several loose standards?

The reason I ask this (am pressing on this) is that a large amount of what 
communicates to the programmer is in the naming and casing convention of the 
words used. 

All too recently, I have had to deal with code where the programmers used 
completely arbitrary conventions to casing absolutely everything.  Methods, 
classes, properties, ivars, methods, functions, all of them were arbitrarily 
named and cased, making converting the code into something manageable a multi 
month lesson in pain.

One very nice thing about Objective-C/Cocoa is that we have naming conventions 
that communicate to the user what we are looking at.  

As we now have the opportunity to take advantage of these techniques that Greg, 
Graham, Quincy, Snej, et al. are bringing to our attention, it's the perfect 
time to at least try out some conventions that clearly tell the programmer what 
the thing is simply by looking at it.

I think it's a prime opportunity to at least start this.

Just my 2 cents on the matter adjusted for inflation.

Alex Zavatone

> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

Re: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

> On Jan 26, 2016, at 6:32 AM, Alex Zavatone  wrote:
> 
> Since we're all computery and programmy and stuff, couldn't we put together a 
> little matrix of the type of variable and come up with several loose 
> standards?
> The reason I ask this (am pressing on this) is that a large amount of what 
> communicates to the programmer is in the naming and casing convention of the 
> words used. 

There is a very longstanding convention in Objective-C — going back to the NeXT 
days — to prefix instance variables with underscores. You’ll see that in many 
of Apple’s headers (the ones that still list ivars in the @interface) and in 
some Apple sample code.

(There was a time when Apple was warning 3rd party developers not to do this 
because of name collisions with inherited ivar names, but that’s a non-issue 
with the modern Obj-C runtime.)

I would strongly urge that anyone prefixing ivars use this convention, for 
consistency. Additionally, I find that the underscore adds less visual clutter 
than a letter like “m”. Your brain doesn’t see it as a letter, so it doesn’t 
get in the way of reading the variable name.

Beyond that it’s a matter of preference. I prefix static variables with “s”, a 
convention that dates back to MacApp (~1988!). I don’t see any reason to prefix 
function parameters or locals in general, since they’re the default, although I 
sometimes use an “out” prefix for a by-reference parameter like an NSError**.

—Jens
___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 2:10 PM, Jens Alfke wrote:

> 
>> On Jan 26, 2016, at 6:32 AM, Alex Zavatone  wrote:
>> 
>> Since we're all computery and programmy and stuff, couldn't we put together 
>> a little matrix of the type of variable and come up with several loose 
>> standards?
>> The reason I ask this (am pressing on this) is that a large amount of what 
>> communicates to the programmer is in the naming and casing convention of the 
>> words used. 
> 
> There is a very longstanding convention in Objective-C — going back to the 
> NeXT days — to prefix instance variables with underscores. You’ll see that in 
> many of Apple’s headers (the ones that still list ivars in the @interface) 
> and in some Apple sample code.
> 

That's the exact first convention that I am aware of which I am referring to.  



> (There was a time when Apple was warning 3rd party developers not to do this 
> because of name collisions with inherited ivar names, but that’s a non-issue 
> with the modern Obj-C runtime.)
> 
> I would strongly urge that anyone prefixing ivars use this convention, for 
> consistency. Additionally, I find that the underscore adds less visual 
> clutter than a letter like “m”. Your brain doesn’t see it as a letter, so it 
> doesn’t get in the way of reading the variable name.

Additionally, when creating an @property, the compiler does this automatically, 
when it create the iVar, correct?

> Beyond that it’s a matter of preference. I prefix static variables with “s”, 
> a convention that dates back to MacApp (~1988!). I don’t see any reason to 
> prefix function parameters or locals in general, since they’re the default, 
> although I sometimes use an “out” prefix for a by-reference parameter like an 
> NSError**.
> 
> —Jens

So, as now as options, we also have:

s to prefix for a static
k for a constant or #define 
my to prefix locals 

With @public and @protected and @private sadly starting with the letter p this 
leaves us without obvious options to connote the style of the variable.

I'm going to step out on a limb and since Xcode has supported editing in UTF-8 
and 16, that we look into those character sets and pick some symbols that 
accurately represent public, protected and private.

These symbols should mean what they represent, and be visually distinct.

They could be put in a little template for copying and pasting when we use them.

The goal here is that when we eyeball our code, we want as much information to 
be presented to us as possible about the nature of each element that we are 
looking at, it's got to be easy to use and visually make sense.

Any ideas for valid characters to prefix @public and @protected and @private 
with?

Here are a few I just pulled up that should display well enough in Menlo 
Regular, but might not make it through email.

  public (megaphone - search the character panel for public)

⊖ ⊗ ⊘ ⊙ ⊞ ⨳ ☒ ⨷ ✖︎ private

℗  ✔︎  protected (second item is the lock character, +1F512)




Reference
http://www.g8production.com/post/69593399838/private-protected-and-public-vars-in-objective-c

UTF-8 Character set
http://www.fileformat.info/info/charset/UTF-8/list.htm
___

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

Re: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

> On Jan 26, 2016, at 12:43 PM, Alex Zavatone  wrote:
> 
> Additionally, when creating an @property, the compiler does this 
> automatically, when it create the iVar, correct?

Only if you have auto-synthesis turned on. (Which it is, by default, but I 
always turn it off because I think it’s a very bad idea: it means a typo in an 
explicit accessor method’s name isn’t a build error, but causes weird runtime 
bugs.)

You have to use `@synthesize foo=_foo`, which is a little annoying. If you just 
say `@synthesize foo`, for some reason it names the ivar `foo` :-p

> With @public and @protected and @private sadly starting with the letter p 
> this leaves us without obvious options to connote the style of the variable.


I don’t see a need to distinguish ivar names by access level. For one thing, it 
should be rare to have protected ivars, and extremely rare to have public ones. 
And besides, it doesn’t seem like such an important distinction that it has to 
be in your face whenever you use the variable. IMHO, it’s _scope_ that’s the 
important thing to make clear in the name.

> I'm going to step out on a limb and since Xcode has supported editing in 
> UTF-8 and 16, that we look into those character sets and pick some symbols 
> that accurately represent public, protected and private.

Now you’re pulling our legs, right Alex?

—Jens
___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

On Jan 26, 2016, at 4:08 PM, Jens Alfke wrote:

> 
>> On Jan 26, 2016, at 12:43 PM, Alex Zavatone  wrote:
>> 
>> Additionally, when creating an @property, the compiler does this 
>> automatically, when it create the iVar, correct?
> 
> Only if you have auto-synthesis turned on. (Which it is, by default, but I 
> always turn it off because I think it’s a very bad idea: it means a typo in 
> an explicit accessor method’s name isn’t a build error, but causes weird 
> runtime bugs.)
> 
> You have to use `@synthesize foo=_foo`, which is a little annoying. If you 
> just say `@synthesize foo`, for some reason it names the ivar `foo` :-p
> 
>> With @public and @protected and @private sadly starting with the letter p 
>> this leaves us without obvious options to connote the style of the variable.
> 
> 
> I don’t see a need to distinguish ivar names by access level. For one thing, 
> it should be rare to have protected ivars, and extremely rare to have public 
> ones. And besides, it doesn’t seem like such an important distinction that it 
> has to be in your face whenever you use the variable. IMHO, it’s _scope_ 
> that’s the important thing to make clear in the name.
> 
>> I'm going to step out on a limb and since Xcode has supported editing in 
>> UTF-8 and 16, that we look into those character sets and pick some symbols 
>> that accurately represent public, protected and private.
> 
> Now you’re pulling our legs, right Alex?

Yeah, I know.  It's really non conventional, buuut… I've started using some of 
the characters such as the block and non breaking line to make better 
formatting for comments and logging.  Other people who are on the Swift side of 
things are even using smilies and emoticons in their code.  Or so they claim.  
That scares me.

I think of it this way, "people have been allowed to program in Xcode in 
Japanese, Chinese and Korean for a while now.  Why not take advantage of the 
graphics in extended character sets if it doesn't break the universe in all 
sorts of ways."

I am more than happy to be proven wrong and be told that this is an utterly 
horrible idea.

Cheers,
Alex Zavatone


___

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

Re: Obj-C - your thoughts on hiding data members?

[Greg Parker]

> On Jan 24, 2016, at 3:55 PM, Graham Cox  wrote:
> 
> In Objective-C 2, data members can be moved into a @interface MyClass () 
> section which lives in the .m file, rather than in the header file as in the 
> classic case. This makes sense - those data members are typically part of the 
> private implementation details of a class and not part of the public 
> interface. 

Even better, you can move them to @implementation itself. No need for the extra 
class extension if everything is used inside a single file.


> But is it worth updating older code to follow this convention? I’ve updated a 
> lot of older code to declare @properties instead of classic getters and 
> setters, and that definitely improves readability. This is a further step I’m 
> contemplating but the benefits are less clear. Do you generally think this is 
> worth doing?

A performance gain. @public and @protected ivars each create an exported 
symbol; @private and @package ivars do not. Reducing symbol exports can improve 
launch time and stripped executable size. Ivars declared in @implementation or 
a class extension @interface are @private by default. Ivars in the primary 
@interface are @protected by default. Therefore you should either move your 
ivars out of the primary @interface, or leave them in @interface but explicitly 
declare them @private or @package.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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

Re: Obj-C - your thoughts on hiding data members?

[Quincey Morris]

On Jan 24, 2016, at 15:55 , Graham Cox  wrote:
> 
> Do you generally think this is worth doing?

I’m not sure its *worth* doing, if you’re looking for a big pay-off, but I 
agree with Jens that I’d probably do it.

Sometimes it can be illuminating to see how small a public interface you need 
to expose. In other cases, it can serve as a kind of code smell to realize that 
the interface remains stubbornly large.

I’d also suggest that “modern” Obj-C code, private @interface () extensions 
tend to disappear completely. You no longer need them for forward-declaring 
file-local methods. You also — perhaps this might seem a bit controversial — no 
longer need them for most default (@synthesize-able) private properties. Since 
ARC and the non-fragile ABI, there’s really no reason to avoid instance 
variables in favor of private synthesized properties, except when there’s 
additional behavior that requires a getter or setter.

In most cases, the only @interface () extensions that remained in my classes 
were for private readwrite overrides of public readonly properties. Almost 
everything else just disappeared. It was a little eerie.

Note that ‘copy’ usually isn’t vital for private properties, because they’re 
mostly NSString values, and even if you set them to a NSMutableString, you 
rarely have any code that’s capable of mutating the string later.

You’d need a property for an 8-byte value that needs to be atomic, but those 
are pretty rare.


___

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

Re: Obj-C - your thoughts on hiding data members?

[Alex Zavatone]

In this effort, what visual convention would you add to the private properties' 
names to indicate to the viewer that these are not public properties?

A prefix of _ is already used by the compiler to indicate the internal ivar 
backing properties so, what convention should be used for private properties?

On Jan 24, 2016, at 8:05 PM, Quincey Morris wrote:

> On Jan 24, 2016, at 15:55 , Graham Cox  wrote:
>> 
>> Do you generally think this is worth doing?
> 
> I’m not sure its *worth* doing, if you’re looking for a big pay-off, but I 
> agree with Jens that I’d probably do it.
> 
> Sometimes it can be illuminating to see how small a public interface you need 
> to expose. In other cases, it can serve as a kind of code smell to realize 
> that the interface remains stubbornly large.
> 
> I’d also suggest that “modern” Obj-C code, private @interface () extensions 
> tend to disappear completely. You no longer need them for forward-declaring 
> file-local methods. You also — perhaps this might seem a bit controversial — 
> no longer need them for most default (@synthesize-able) private properties. 
> Since ARC and the non-fragile ABI, there’s really no reason to avoid instance 
> variables in favor of private synthesized properties, except when there’s 
> additional behavior that requires a getter or setter.
> 
> In most cases, the only @interface () extensions that remained in my classes 
> were for private readwrite overrides of public readonly properties. Almost 
> everything else just disappeared. It was a little eerie.
> 
> Note that ‘copy’ usually isn’t vital for private properties, because they’re 
> mostly NSString values, and even if you set them to a NSMutableString, you 
> rarely have any code that’s capable of mutating the string later.
> 
> You’d need a property for an 8-byte value that needs to be atomic, but those 
> are pretty rare.
> 
> 
> ___
> 
> 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/zav%40mac.com
> 
> This email sent to z...@mac.com


___

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

Re: Obj-C - your thoughts on hiding data members?

[Jens Alfke]

I do; it makes the @interface shorter and easier to read, and afterwards if you 
change/add/remove an instance variable, it only touches the .m file, so it 
doesn’t force a bunch of other files to recompile.

—Jens
___

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

Re: Obj-C - your thoughts on hiding data members?

[Quincey Morris]

On Jan 24, 2016, at 17:34 , Alex Zavatone  wrote:
> 
> A prefix of _ is already used by the compiler to indicate the internal ivar 
> backing properties so, what convention should be used for private properties?

That's kinda a whole different discussion. In Graham’s case, the properties 
were already private, but they just happened to have been exposed in the public 
header file. Presumably, they would keep the same names when moved to the 
implementation file.

In general, use of naming conventions is a personal opinion that we’re never 
going to reach consensus on. I happen to be at the unpopular end of this — I’ve 
never used a syntactic naming convention for variables, other than the forced 
“_” for backing variables that correspond to synthesized properties — and it’s 
pretty lonely down here on the bendy end of the tree branch.

___

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

Obj-C - your thoughts on hiding data members?

[Graham Cox]

In Objective-C 2, data members can be moved into a @interface MyClass () 
section which lives in the .m file, rather than in the header file as in the 
classic case. This makes sense - those data members are typically part of the 
private implementation details of a class and not part of the public interface. 

But is it worth updating older code to follow this convention? I’ve updated a 
lot of older code to declare @properties instead of classic getters and 
setters, and that definitely improves readability. This is a further step I’m 
contemplating but the benefits are less clear. Do you generally think this is 
worth doing?


—Graham



___

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