4 ms·

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 h

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.
- pjmlp 8y ago
  And even Smalltalk had many ideas from FP, like blocks (closures) and the collection messages similar to what modern developers know as LINQ.
- mariodiana 8y ago
  Okay, the context of the reply to which I was initially replying to was about how the implementation of generics in Objective-C was "very bare." I'm beginning with this point, because though I agree with your second point about OOP perhaps not being necessarily "the best paradigm for coding problems developers face today," I don't quite see where that point fits in. We're talking about Objective-C, which means we're talking about OOP. If you want to explore some other kind of programming paradigm and insist that generics are needed there, I have no quarrel with you. My point was that I didn't see why generics were needed in OOP. But that brings us to your first point: namely, what is the "right" way to approach OOP. When I bring up Alan Kay, I'm bringing up a guy who was there at the start, and who set his stamp on OOP. Granted, "OOP" has been done in different ways. You'll note, however, my use of scare quotes. Allow me to explain. When OOP had the misfortune to become a managerial buzz, somewhere back in the 1990's, and thus became a "must-have," what happened was a lot of procedural programmers simply took their procedural programming, wrapped in in C++, compiled it with a C++ compiler, nodded to the boss and assured him that they were doing OOP—and went along on their happy way. Likewise, when college professors—set in their ways, as is their want—were told that they had to start teaching OOP, they largely did the same thing. The result is that we have lots and lots of people out in the world "doing OOP"—who actually aren't. They're writing procedural programs, with the trappings of classes and sub-classing and what not. But all over in their programs, they are digging into the internals of their classes—and, sometimes, you see them digging in many layers deep. And they're "doing OOP." As I understand him, Kay is saying that you send a message to an object, on the understanding that the object will handle the message, the sender not having to worry about the ultimate who or how. If there's another kind of OOP other than that—or other than the travesty I described above—what is it? But, that's another question, entirely. My original question was: why are generics such a big deal in OOP? I don't believe that's been answered.
zoul 8y ago
For me, the big deal about generics is that they allow the type system to cover a much bigger part of my design. Without generics, any parametrized API will erase your types and then the compiler is blind. With generics the type information is preserved and when I specify a parameter type, somewhere several API layers away a type is suddenly fixed, too. That gives me a warm feeling (and code completion, too). And since expressive static type systems seem to be the right way to go, allowing the type system better insight into your code is a big win.

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.

pjmlp 8y ago
And even Smalltalk had many ideas from FP, like blocks (closures) and the collection messages similar to what modern developers know as LINQ.
mariodiana 8y ago
Okay, the context of the reply to which I was initially replying to was about how the implementation of generics in Objective-C was "very bare." I'm beginning with this point, because though I agree with your second point about OOP perhaps not being necessarily "the best paradigm for coding problems developers face today," I don't quite see where that point fits in. We're talking about Objective-C, which means we're talking about OOP. If you want to explore some other kind of programming paradigm and insist that generics are needed there, I have no quarrel with you. My point was that I didn't see why generics were needed in OOP. But that brings us to your first point: namely, what is the "right" way to approach OOP. When I bring up Alan Kay, I'm bringing up a guy who was there at the start, and who set his stamp on OOP. Granted, "OOP" has been done in different ways. You'll note, however, my use of scare quotes. Allow me to explain. When OOP had the misfortune to become a managerial buzz, somewhere back in the 1990's, and thus became a "must-have," what happened was a lot of procedural programmers simply took their procedural programming, wrapped in in C++, compiled it with a C++ compiler, nodded to the boss and assured him that they were doing OOP—and went along on their happy way. Likewise, when college professors—set in their ways, as is their want—were told that they had to start teaching OOP, they largely did the same thing. The result is that we have lots and lots of people out in the world "doing OOP"—who actually aren't. They're writing procedural programs, with the trappings of classes and sub-classing and what not. But all over in their programs, they are digging into the internals of their classes—and, sometimes, you see them digging in many layers deep. And they're "doing OOP." As I understand him, Kay is saying that you send a message to an object, on the understanding that the object will handle the message, the sender not having to worry about the ultimate who or how. If there's another kind of OOP other than that—or other than the travesty I described above—what is it? But, that's another question, entirely. My original question was: why are generics such a big deal in OOP? I don't believe that's been answered.

zoul 8y ago

For me, the big deal about generics is that they allow the type system to cover a much bigger part of my design. Without generics, any parametrized API will erase your types and then the compiler is blind. With generics the type information is preserved and when I specify a parameter type, somewhere several API layers away a type is suddenly fixed, too. That gives me a warm feeling (and code completion, too). And since expressive static type systems seem to be the right way to go, allowing the type system better insight into your code is a big win.