14 ms·

I love Objective-C, but calling it (close to) a modern language is a long stretch. The “generics” are a joke, for example. The whole type system is miles from w

by zoul 8y ago

I love Objective-C, but calling it (close to) a modern language is a long stretch. The “generics” are a joke, for example. The whole type system is miles from what can be expressed (and guaranteed!) by a modern language. We got an immense amount of fun out of it considering its age, but it’s time to move on.

tsycho 8y ago
Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift. "Simple" things I want from generics: 1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id". 2. A compiler flag to enforce that the generic type must be specified at usage. 3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>> 4. Generics on protocols, ideally with all the other features. I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).
- saagarjha 8y ago
  I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.
  - valuearb 8y ago
    Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?
    - saagarjha 8y ago
      The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.
- mariodiana 8y ago
  I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better? I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming. If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program. Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of. So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?
  - valuearb 8y ago
    Your array of NSString example has little to do with generics. Instead think of a class that contains an NSArray, and has methods to do specific things to the array items, for example a sort() method. Using generics you can define the array values to match the type given when the class is created. So the same class could contain NSStrings, UImages, UIControls, etc, etc, and sort accordingly.
  - slavapestov 8y ago
    Alan Kay’s ideas are very interesting and Smalltalk introduced many groundbreaking ideas that still inspire programmers today. But there’s no fundamental law of nature that says dynamic message passing OOP is the “right” way to approach OOP, or even that OOP is the best paradigm for many coding problems developers face today.
- slavapestov 8y ago
  A fundamental problem with Objective-C generics that cannot be addressed in an additive manner is that generic parameters just desugar to ‘id’; you cannot use Objective-C generics with C types and you still pay the performance and memory use cost of trafficking exclusively in class instances. This of course was the right trade off, since it allowed generics to be layered on top of existing types like NSArray without either changing their implementation or breaking existing client code. However, when designing a new language with generics built in from the start you can make much better design decisions.

by zoul 8y ago

tsycho 8y ago

Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift. "Simple" things I want from generics: 1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id". 2. A compiler flag to enforce that the generic type must be specified at usage. 3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>> 4. Generics on protocols, ideally with all the other features. I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).

saagarjha 8y ago
I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.
- valuearb 8y ago
  Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?
  - saagarjha 8y ago
    The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.
mariodiana 8y ago
I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better? I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming. If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program. Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of. So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?
- valuearb 8y ago
  Your array of NSString example has little to do with generics. Instead think of a class that contains an NSArray, and has methods to do specific things to the array items, for example a sort() method. Using generics you can define the array values to match the type given when the class is created. So the same class could contain NSStrings, UImages, UIControls, etc, etc, and sort accordingly.
- slavapestov 8y ago
  Alan Kay’s ideas are very interesting and Smalltalk introduced many groundbreaking ideas that still inspire programmers today. But there’s no fundamental law of nature that says dynamic message passing OOP is the “right” way to approach OOP, or even that OOP is the best paradigm for many coding problems developers face today.
slavapestov 8y ago
A fundamental problem with Objective-C generics that cannot be addressed in an additive manner is that generic parameters just desugar to ‘id’; you cannot use Objective-C generics with C types and you still pay the performance and memory use cost of trafficking exclusively in class instances. This of course was the right trade off, since it allowed generics to be layered on top of existing types like NSArray without either changing their implementation or breaking existing client code. However, when designing a new language with generics built in from the start you can make much better design decisions.