• 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: Obj-C - your thoughts on hiding data members?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Subject: Re: Obj-C - your thoughts on hiding data members?
  • From: Alex Zavatone <email@hidden>
  • Date: Tue, 26 Jan 2016 16:46:45 -0500

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

>
>> On Jan 26, 2016, at 12:43 PM, Alex Zavatone <email@hidden> 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 (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


  • Follow-Ups:
    • Re: Obj-C - your thoughts on hiding data members?
      • From: Dave <email@hidden>
References: 
 >Obj-C - your thoughts on hiding data members? (From: Graham Cox <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Greg Parker <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Alex Zavatone <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Dave <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Alex Zavatone <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Jens Alfke <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Alex Zavatone <email@hidden>)
 >Re: Obj-C - your thoughts on hiding data members? (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: LGPL code in the Mac App Store?
  • Next by Date: Re: LGPL code in the Mac App Store?
  • Previous by thread: Re: Obj-C - your thoughts on hiding data members?
  • Next by thread: Re: Obj-C - your thoughts on hiding data members?
  • Index(es):
    • Date
    • Thread