Adopting Objective-C Generics
1–10 of 19 posts
Re: Adopting Objective-C Generics
#2I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics.
So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
Re: Adopting Objective-C Generics
#3I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
If you don't see the point of generics... just go back to using dynamic languages...
Re: Adopting Objective-C Generics
#4I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
> So why was this added to the language?
For Swift's benefit. The types come across the ObjC-Swift bridge. It's a big pain to deal with arrays typed as [AnyObject] in Swift, so this helps.
Re: Adopting Objective-C Generics
#5I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
I've never had an error where I added the wrong kind of object to an array.
I have, however, spent untold cumulative hours looking up the documentation of a call that took or returned NSArray* just to see what kind of objects it expected or provided in that array.
Cocoa is filled with methods like:
- (NSArray *)items;
Sometimes it's obvious, sometimes it's not. Sometimes you have to look up the documentation and see. Sometimes, if you're really unlucky, you have to just print the thing out at runtime and see. It's almost always a pain in the ass.
Good Objective-C code will add a comment to the above to the effect of, // This returns an array of MyFooItem instances. This allows the programmer to quickly see what they can expect. Generics just formalizes this and puts it in a form that the compiler can understand. What's so bad about that?
Re: Adopting Objective-C Generics
#6I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
Nothing wrong with a nice bit of CS dogma! You're welcome to ignore what those fancy pants doctors with their clever titles tell you to do. After all, they just read a few books, and books could say anything. But for my part, I think this is a good move, since I don't think "practically never" is a very high bar ;)
With static checks, you can guarantee this absolutely never happens. Whether Objective-C's checks reach are as exhaustive as they could be, I don't know, but I think this seems to be one case where the future is turning out to be actual genuine progress rather than merely the inevitable outcome of the passage of time.
Re: Adopting Objective-C Generics
#7I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
these generics finally let you use property notation with arrays; you can now do something like 'names[i].length' or 'self.tableView.tableColumns.firstObject.identifier'.
Of course since you are programming since 14 years, maybe you never switched to property notation? In that case you'll at least profit from better autocomplete.
Re: Adopting Objective-C Generics
#8I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
I've never had an error where I added the wrong kind of object to an array. I have, however, spent untold cumulative hours looking up the documentation of a call that took or returned NSArray* just to see what kind of objects it expected or provided in that array. Cocoa is filled with methods like: - (NSArray *)items; What does it return? An array! What's in the array? Items! What class represents items? Who knows! S…
There's nothing wrong with that, it's nice. But that's all it is IMHO -- just nice. So I'm not sure why they're bothering to add it to Objective-C now.
One of the reasons I've always liked Obj-C is that it is (was) such a thin layer over C, and the amount of new syntax was minimal. Devising new ways to litter code with brackets smells suspiciously like C++.
Re: Adopting Objective-C Generics
#9Curious as to how this actually works under the hood.
This looks like type erasure (checking the types in the compiler but treating everything as id under the hood, similar to what Java does), whereas swift, if I'm not mistaken, uses reification for generics (creating separate copies of each class/function for each parameter type used in the application).
Does that mean that the compiler is doing erasure for generics coming in from Objective C, inserting runtime casts where needed, but then doing full reification on swift code?
Seems like that would have to be how it works, no?
Re: Adopting Objective-C Generics
#10I've been programming in Obj-C for 14 years. When I started, I was worried about adding the wrong kind of object into an NSArray. But turns out that this practically never happens. I can't remember the last time I had a bug that would have been prevented by generics. So why was this added to the language? I have no idea. I guess it's just some kind of CS dogma -- the same that guided the design of Swift.
these generics finally let you use property notation with arrays; you can now do something like 'names[i].length' or 'self.tableView.tableColumns.firstObject.identifier'. Of course since you are programming since 14 years, maybe you never switched to property notation? In that case you'll at least profit from better autocomplete.
Well, you got me there -- I honestly feel that property notation was not a very good addition to Obj-C because it looks like C struct access yet is incompatible with it. It's supremely annoying that I can't write "view.frame.origin.x += 10"...
But I do use property notation, if only because not doing so would probably drive my co-workers crazy. It's more important to write code that is readable in context; nobody cares about my personal syntactic tastes. (That's of course why I like to whine about them on HN.)