Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adopting Objective-C Generics

miqu.me

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Adopting Objective-C Generics

#11

Post by mikeash »

pavlov wrote: post #8
mikeash wrote: post #5

Earlier quoted context omitted.

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++.

The question of "why?" is as above, the question of "why now?" is to make it work more nicely with Swift.

This addition is so distant from C++ that New Horizons hasn't even reached it yet.

Re: Adopting Objective-C Generics

#12

Post by mikeash »

kinofcain wrote: post #9

Curious 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…

There's not much reification to be done when dealing with ObjC objects and calling ObjC methods. For example:

    let a = A()
    a.someMethod()
    
    let b = B()
    b.someMethod()
If A and B are Swift types, then the code to invoke a.someMethod() might be substantially different from the code for b.someMethod(). There's struct versus class, final methods, the potential for inlining, maybe more.

If A and B are both Objective-C classes, however, then the code for the two invocations is identical. Both will compile down to a call to objc_msgSend, passing the object and the "someMethod" selector to it as parameters.

So yes, it looks like the types get erased on the ObjC end of things, but I don't think the Swift end of things has to care very much. It can emit code without any runtime casts or any adjustment for the actual generic type.

Re: Adopting Objective-C Generics

#14

Post by pavlov »

to3m wrote: post #6
pavlov wrote: post #2

I'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…

You have to understand that Obj-C is sort of a single-purpose language: it's primarily used for user interface code.

Most larger projects (including most of Apple's own software) have a C++ core underlying an Objective-C GUI layer. This split is actually quite useful in practice. C++ language features are useful for data modelling, whereas Obj-C's dynamism is useful for building GUIs.

Hence I feel that Obj-C doesn't automatically benefit from new C++-like syntax, because real-world code is already using C++ for the sections of code where it matters.

The interactions between C, C++ and Obj-C are already pretty complex. Adding new syntax into Obj-C may only muddy the waters further. I'm not sure if it's worth adding stuff to Obj-C at this point in its history.

Re: Adopting Objective-C Generics

#16

Post by saurik »

pavlov wrote: post #2

I'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 heavily lean on the type system less for "no bugs" (though frankly I am surprised that you never accidentally confuse a list of URLs stored as NSString with a list of NSURLs ;P) and more for helping me rapidly refactor my codebase: I can make some signature changes and then let the compiler walk me through the required remaining changes.

Re: Adopting Objective-C Generics

#17

Post by [deleted] »

pavlov wrote: post #14
to3m wrote: post #6

Earlier quoted context omitted.

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…

You have to understand that Obj-C is sort of a single-purpose language: it's primarily used for user interface code. Most larger projects (including most of Apple's own software) have a C++ core underlying an Objective-C GUI layer. This split is actually quite useful in practice. C++ language features are useful for data modelling, whereas Obj-C's dynamism is useful for building GUIs. Hence I feel that Obj-C doesn't…

[deleted]

Re: Adopting Objective-C Generics

#18

Post by potatolicious »

pavlov wrote: post #8
mikeash wrote: post #5

Earlier quoted context omitted.

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++.

They're adding it to Objective-C now to make it interop better with Swift.

Objective-C classes have Swift interfaces automatically generated so you can call them from Swift code. Up until now this has been pretty shitty, since Swift is overall a stricter language than Obj-C. e.g., calls in Swift can enforce a return value to be non-nil, but Obj-C cannot, therefore all Obj-C-Swift interfaces leaves these values in an unknown nullable state even if the code itself makes guarantees on nilness.

The "nice" bits being added allow proper generation of Swift interfaces so that Swift code calling Obj-C code doesn't lose type safety (or nil-safety).

Re: Adopting Objective-C Generics

#19

Post by netheril96 »

kinofcain wrote: post #9

Curious 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…

> Does that mean that the compiler is doing erasure for generics coming in from Objective C, inserting runtime casts where needed

The runtime types of Obj-C objects do not matter, as long as they can respond to the messages sent to them. In fact, you can cast any object to any class and gets no runtime errors, as long as the message you send is recognized. So reification is really not something useful in Obj-C.

Post reply on HN