Objective-C Generics(github.com)
github.com
Objective-C Generics
https://github.com/tomersh/Objective-C-Generics
29 comments
> 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.
... and nearly nobody would have a clue what you meant.
> 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.
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.
Yes 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.
So this is just going to cause confusion, though I am very impressed with all the long words you used.
In 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.
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.
Generics 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.
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.
Types aren't just for the compiler and runtime, they're also to communicate intent to other programmers and future instances of self.
As 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]
The only thing that makes sense is something like categories, as a way to specify an expected set of operations, which Objective-C already has.
This 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.
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.
Other 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.
If type-safety is that important, a custom collection class will enrich your domain model and be more obvious.
Viewing the source code, it does seem to support sets and dictionaries.
This 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.
This 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...
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...
It 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.
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.
> it'd break runtime method replacement and all sorts of other stuff.
yeah, i thought as much. thanks for saving me the effort. :)
yeah, i thought as much. thanks for saving me the effort. :)
That'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.
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.
I'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
Edit: here's the issue: https://github.com/tomersh/Objective-C-Generics/issues/4
just... why?
Cue pointless duck typing flamewar...
where is the bottle neck in such code? why is this faster than say Norvig spell checker? http://norvig.com/spell-correct.html
don't be a dick, just answer the question.
I think you meant to reply to the "1000x Faster Spelling Correction: Source Code released" comment section.
https://news.ycombinator.com/item?id=7048225
Oh, don't be a dick if I am wrong.
https://news.ycombinator.com/item?id=7048225
Oh, don't be a dick if I am wrong.
congratulations! you're a dick
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."