Comments on: Proposal: generics (and some other stuff) for Objective-C

By: Jens Ayton

Jens Ayton — Mon, 28 Jun 2010 19:09:33 +0000

It wouldn’t break supersetosity if var could be redefined, somewhat analogous to the way self can be used in non-method contexts. But that would cause new problems, so I agree – an @-keyword would be better, yet uglier. (It could perhaps be defined to a normal identifier in a standard header, just as id is typedefed, or bool is in C99.)

By: Ondra Hošek

Ondra Hošek — Mon, 28 Jun 2010 18:56:08 +0000

I might be a bit late to the fray, but calling the infer-me type “var” would break ObjC’s strict-superset-ness, since I’d not be able to declare an “int var;” anymore. This is very probably the reason why every ObjC keyword is prefixed with an @ sign.

By: Jens Ayton

Jens Ayton — Mon, 16 Nov 2009 23:16:09 +0000

“…add this metadata to the interface” is a good phrase. Every now and then, I read or write code like: - (NSArray *) frobs; // Array of JAFrob This is suboptimal for – once again – exactly the same reason - (id) frobs; // NSArray of JAFrob would be. The genericized form, - (NSArray[JAFrob] *) frobs; gives you the whole scoop in one place consistently with non-container methods.

By: Jesper

Jesper — Mon, 16 Nov 2009 23:07:23 +0000

I had a list of things to put after that sentence, but I decided not to; everything there could be argued against with something that could be answered with that sentence. (For better or worse.) Now I’m going to spell it out anyway, though, since we really may not be on the same page.

*Usually*, the temporary variable is not a problem. You’re right that it’s not the end of the world. Sometimes you end up with treacherous pairs. `length` exists on both NSString and on NSData, and `count` on a bunch of different collections. (They happen to have the same semantics, but that’s not why they’re treacherous, it’s because they block the compiler warning or error from happening.)

In some cases you change a data type somewhere and the code you used for removing/enumerating objects from one collection and inserting into another either doesn’t do any logic on the object or happens to do the exact operation that’s sort of available on both, and you end up pushing an object of the entirely wrong kind of class somewhere else, and you have to go hunt for the bug.

Like Ayton said, ask yourself again why you use the temporary variable. Casting (or even just plain assignment) certainly doesn’t convert the object or throw if it fails. It’s there for documentation for your eyes, and to enable Code Sense. If that can be done with fewer lines of code, help keep the variables down to the ones you actually want to have around and last but not least add this metadata to the interface in the first place (we’ve been talking about implementation), I don’t see why it’s not worthwhile.

By: Jens Ayton

Jens Ayton — Fri, 13 Nov 2009 19:55:42 +0000

Well, I certainly can’t beat Jesper at succinctness.

To quote myself: “The idea is to provide information that helps the compiler and analyzer check your logic, and the IDE to provide better suggestions.” Exactly like static typing in general, then.

For example, if I have a heterogeneous dictionary, and type [[someDict objectForKey:key] st], I want relevant suggestions. If I use a method that the value type doesn’t have, I want to be warned about it. If you don’t see these as advantages, why don’t you use id everywhere?

The “ just sane use of temporary variables” thing sounds to me like you’re desensitized to a workaround.

By: Jesper

Jesper — Fri, 13 Nov 2009 17:43:03 +0000

mike: The types in generics are useful for exactly the same reason the types everywhere else are useful.

By: mikeash

mikeash — Thu, 12 Nov 2009 23:08:14 +0000

I like the contextual types proposal. This sort of thing has been annoying, and occasionally destructive, for quite a while. I hope Apple adopts something like this.

I don’t really get the generics proposal, though. Mistakes due to forgetting what sort of object are in a collection are, in my experience, rare and easily caught. Very, very occasionally you run into problems because -objectAtIndex: returns id and this results in type confusion, but with for/in loops or just sane use of temporary variables this doesn’t really happen. Is there a specific use case beyond this that I’m missing?

By: Uros Dimitrijevic

Uros Dimitrijevic — Sun, 08 Nov 2009 01:31:44 +0000

Interesting. Sort of like Java generics but with the flexibility of Objective-C. Although one thing that I can’t seem to ignore is the complexity this would add to the language, however negligible its impact would be on backwards-compatibility.

Oh, and on calling the inferred type ‘ego’: priceless. (Does that mean I wasn’t mistaken in not pronouncing the ‘id’ type ‘eye-dee’?)

By: Joachim Bengtsson

Joachim Bengtsson — Mon, 05 Oct 2009 21:43:17 +0000

I really like it, actually! Then again, I’m starting to warm up to C++ again… Maybe I’m just mad. Really like that ‘auto’ keyword too, that’ll ease C++ coding.