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."
... and nearly nobody would have a clue what you meant.
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.
So this is just going to cause confusion, though I am very impressed with all the long words you used.
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.
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.
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.
If type-safety is that important, a custom collection class will enrich your domain model and be more obvious.
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...
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.
yeah, i thought as much. thanks for saving me the effort. :)
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.
Edit: here's the issue: https://github.com/tomersh/Objective-C-Generics/issues/4
Oh, don't be a dick if I am wrong.