Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

An Open Letter to Apple: Please Kill Synthesis in iOS 6!

DZone's Guide to

An Open Letter to Apple: Please Kill Synthesis in iOS 6!

· Mobile Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

And John Blanco penned an open letter to Apple…

Dear Apple,

The gig is up. I see what you’re doing. You’re trying to fix one of biggest follies of iOS development that the mainstream doesn’t know about but us developers do. You want to kill Objective-C.

It’s obvious. No no, it’s not that you added properties and then blocks. Those are awesome language features. The problem is that you already knew they were awesome language features because all other modern languages have them. No, it’s what you silently did with much less fanfare:

You removed the need to define ivars for synthesized fields.

A lot of iOS developers still don’t realize this. For example, this compiles and works:

@interface Foo
 
@property (assign) fooNumber;
 
@end
 
@implementation
 
@synthesize fooNumber = fooNumber_;
 
...
 
@end

Indeed, we no longer have to declare fooNumber_ as an ivar. And thank you for it. It’s one less place I have to replicate a field name in order to add one. You recognize that to add a field to a class prior to this, you had to declare all of the following:

  • The ivar.
  • The property.
  • The synthesizer.
  • The deallocation.
  • The memory management on the setter (if applicable).

Five places! Six if you count the getter, but I’ll give you a pass. FIVE PLACES. But, then you eliminated one:

  • The ivar.
  • The property.
  • The synthesizer.
  • The deallocation.
  • The memory management on the setter (if applicable).

Now, iOS 5 has come out, along with the ARC system. And lo and behold, you got rid of the deallocation. And this glorious thing happened:

  • The ivar.
  • The property.
  • The synthesizer.
  • The deallocation.
  • The memory management on the setter (if applicable).

Yes, I might still need to write a setter, but if I do I don’t have to manage the memory. And, if I override the setter, it’s no different than any other language. The synthesis will do it for me if I don’t.

But now I have a demand.

Please make @synthesize implicit!

I know you can do it. You did ARC and ARC is inserting code for us even though it’s not there. Why not do the same for properties? How about letting this code fly:

@interface Foo
 
@property (assign) fooNumber;
 
@end
 
@implementation
 
...
 
@end

How glorious! I can define a field in ONE place! Here’s how it’d work:

  1. Every property is automatically synthesized.
  2. The property name is set to fooNumber_. It’s OK to assume, that’s what you’ve told the developers to do.
  3. If I want to override a setter or getter, I can just do it.

I am racking my brain and I can think of no reason why this can’t be done. And you know what? You’re gonna do it. Come iOS 6, this will be how it is. I know it! So please, just do it. You gave us ARC and are already making our brains meld to the new form. So, just end the misery. Let’s make this the new list and rejoice:

  • The ivar.
  • The property.
  • The synthesizer.
  • The deallocation.
  • The memory management on the setter (if applicable).

PS – Sorry about Steve. :-(

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:

Published at DZone with permission of John Blanco, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}