User:Maury Markowitz/ObjC wishlist

From Wikipedia, the free encyclopedia

This is a whiteboard for listing and ranking improvements to Objective-C.

1. auto "boxing"
   certainly one of the nicer features of C# is the auto-boxing, which would be just as useful in ObjC as any other language. Combined with stack-based objects this operation can be made very cheap, less expensive than rolling the same code by hand and using GC to clean up.
2. stack-based objects
   as I understand it, modern compilers can do this internally in their optimizers. IE, no need to specify you want object xxx to be built on the stack, just tell the compiler you want to use them when appropriate and off it goes.
3. garbage collection
   "real programmers" always complain about this, but the argument is long dead. Quoting examples of poor GC, like in Java, is not a good argument against GC. Almost all Macs produced today have two cores, and since modern GC is multi-threaded, the performance-based arguments against it continue to grow weaker as time goes on. Note: they're putting this into XCode 3, we'll have to see how well it works.
4. inlining of objects/functions/etc
   This also appears to be a feature that the compiler/optimizer can handle internally.
5. "high level syntax"
   This is basically a "for each x in y do" syntax. Smalltalk's implementation wasn't particularily pretty, and the POC's is downright ugly, but I have seen proposals for ObjC versions that look extremely nice. It can be combined with the item below to actually improve performance as well. Note: they're putting this into XCode 3.
6. safe marker
   One performance improvement "trick" in ObjC is to lock down function references in loops by pulling out the signature and calling the functions directly. This is only really useful for large collections. Someone proposed adding a "safe" keyword which would tell the compiler that the function pointers would not be changing (easy enough in a tight loop). However, a compiler/optimizer that does this for you would be even nicer.
7. optionally combine interface and implementation in a single physical file
   There is simply no reason for this split of files to exist any more; modern compilers don't need to rely solely on disk timestamps to figure out what needs to be done. Maintaining a single file is much easier for everyone, notably future code maintainers, and you can still generate "header like" files from the data if you want to put it into a bundle or other packaging.
8. multiple named interfaces
   If there is one feature I would like to see from Dylan in ObjC, it's the ability to create multiple interfaces for any definition. This allows the developer to publish multiple versions of the same object, for instance, a single implementation with a "public" and "private" interfaces. This sounds similar to what you might see in Java or C#, but it has a number of major advantages. One is that you can change the definition from private to public without changing the definition itself, which leads to dramatically improved DIFFs and code control (think about it). But it also means you can make a different set of interfaces exposed for different versions, for instance "v1production" and "v2beta", simply different sets of published interfaces for the identical code.
9. namespaces
   I can't stand the name of this feature, but its usefulness I don't argue with.
10. renaming
    And it would be really nice to be able to import objects and strip off parts of their names, like all the "NS"'s that are stuck on NSObject, NSString, etc.