6 ms·
Objective-C Generics
- fleitz 13y agoGenerics don't make much sense in dynamic languages. You don't need to cast to the correct class to call a method. If the only selector you use is length then any object that responds to length will work.
- pjmlp 13y agoThe only thing that makes sense is something like categories, as a way to specify an expected set of operations, which Objective-C already has.
- ryanpetrich 13y agoTypes aren't just for the compiler and runtime, they're also to communicate intent to other programmers and future instances of self.
- cageface 13y agoAs other posters have stated, they're very useful for collection classes. I've had a lot of stupid bugs in Obj-C that would have been caught by the compiler if it could verify that only the right kinds of objects are going into an NSArray, for instance.
- deleted 13y ago[deleted]
- my3681 13y agoThis is, in my opinion, the best answer. The dynamic nature of the language is something that allows for great flexibility, especially in passing objects of varying types down the road until it is time for them to be displayed. For example, if I have a news aggregator that keeps an array of 4-5 types of article objects, I may want to process them differently in a UITableView. I could store them all in the array and then do type checking at the time they should be rendered to determine how each are displayed. Of course, this can be achieved in statically typed languages as well if, say, each article class inherited from a common class, but what if they don't? On that note, does anyone know how this library handles inheritance? This library would definitely help if you prefer the statically typed languages, but I would be wary of losing the freedom of Objective-C. Instead of binding data containers to types, perhaps good documentation and clearly written code is more the answer.
- RyanZAG 13y agoThis is pretty awesome - it detects a lot of potential bugs you can miss when moving objects into and out of collections and ensures you always know what types of objects are expected when passing collections into other controllers. I'll definitely be giving it a try, thanks.
- greatsuccess 13y agoCue pointless duck typing flamewar...
- seivan 13y agoHow well does this work? If it works as intended, then this is great!
- deleted 13y ago[deleted]
- pkaler 13y agoThis isn't really generics in the C++ or Ada sense. This is code replacement using preprocessor macros and the stringize operator to create homogenous containers. Generic programming usually implies that a package, class, or function is parameterized by types. And a generic/template instantiation phase has been added to the toolchain after the preprocess stage but before the type checking phase. I would have called this homogenous containers. >> Now you can use generics with arrays and sets just as you normally do in Java, C#, etc. I would have documented that as: "Now you can use homogeneous containers with arrays and sets just as you normally do in Java, C#, etc."
- jheriko 13y ago> I would have documented that as: "Now you can use homogeneous containers with arrays and sets just as you normally do in Java, C#, etc." ... and nearly nobody would have a clue what you meant.
- cowls 13y agoYes they are actually called generics in Java.. So this is just going to cause confusion, though I am very impressed with all the long words you used.
- smikhanov 13y agoIn Java, generics is a possibility to parametrize any type (not just a container) with another type. Just like in any other language that support generics. If you limit generics in Java to container types only (like at the original link), it would be absolutely more correct to call the result "homogenous containers". Take Callable<T>, for example. This is a generic type that is not a container and is not in the scope of project at the OP's link.
- pkolaczk 13y ago> This is code replacement using preprocessor macros and the stringize operator to create homogenous containers. Well, C++ templates are technically done by macro substitution, too, just they happen in a different stage of the compiler toolchain. > And a generic/template instantiation phase has been added to the toolchain after the preprocess stage but before the type checking phase. No, real generics are a part of the type-system; they should be part of the type-checking, not a magic preprocessing step. Therefore the compiler can do many cool things like imposing generic type constraints and also it can improve error messages a lot. So actually this solution is much, much closer to C++ templates, than to Java/Haskell/Scala/C# generics.
- jheriko 13y agoThis is interesting - a 'clever' trick to give the functionality of generics. Although one could argue that its also fantastically stupid by using a macro in such a way that isn't obvious on inspection and might necessitate reading the header. I do quite like it however... I'd imagine that Objective-C prevents any of the performance benefits gained by the compiler knowing the types with its heavyweight super dynamic late binding golden sledgehammer of an architecture. I'd be curious to measure it when I get some time...
- chrisdevereux 13y agoIt won't. If the compiler attempted to inline, it'd break runtime method replacement and all sorts of other stuff. One problem with this approach is that using protocols to emulate C++/Java generic syntax will cause name collisions if a class already has the same name as a protocol. NSArray<NSObject> won't work for example, because NSObject is already a protocol.
- jheriko 13y ago> it'd break runtime method replacement and all sorts of other stuff. yeah, i thought as much. thanks for saving me the effort. :)
- fleitz 13y agoThat's actually what I really like about ObjC, either it's ok to be kinda slow, or you're writing it in C/C++. ObjC is like a super fast ruby with a C/C++ compiler embedded. Most of the core types are toll-free bridged so you can drop the ObjC overhead pretty quick.
- mogui 13y agojust... why?
- lukeredpath 13y agoOther than adding dozens of methods to NSArray/MutableArray for each "generic" you define and limiting my choice of collection to an array (rather than a set or dictionary), why would you use this rather than define your own collection class that keeps the underlying store encapsulated and enforces its own type-safety? If type-safety is that important, a custom collection class will enrich your domain model and be more obvious.
- btown 13y agoViewing the source code, it does seem to support sets and dictionaries.
- mrcactu5 13y agowhere is the bottle neck in such code? why is this faster than say Norvig spell checker? http://norvig.com/spell-correct.html http://norvig.com/spell-correct.html
- mrcactu5 13y agodon't be a dick, just answer the question.
- sgt 13y agoDoes this work outside of the classes defined in ObjectiveCGenerics.h? E.g. outside of NSArray, NSSet, NSMutableArray and so on.
- Tloewald 13y agoClearly not. (Or do you mean, could support be added for other things?)
- MaxGabriel 13y agoI'm pretty sure with this implementation you can't have multiple generics in one file because the macros clash or something (working off memory here). Edit: here's the issue: https://github.com/tomersh/Objective-C-Generics/issues/4 https://github.com/tomersh/Objective-C-Generics/issues/4