Objective-C has no namespaces; it's much like C, everything is within one global namespace. Common practice is to prefix classes with initials, e.g. if you are working at IBM, you could prefix them with "IBM"; if you work for Microsoft, you could use "MS"; and so on. Sometimes the initials refer to the project, e.g. Adium prefixes classes with "AI" (as there is no company behind it of that you could take the initials). Apple prefixes classes with NS and says this prefix is reserved for Apple only.
So far so well. But appending 2 to 4 letters to a class name in front is a very, very limited namespace. E.g. MS or AI could have an entirely different meanings (AI could be Artificial Intelligence for example) and some other developer might decide to use them and create an equally named class. Bang, namespace collision.
Okay, if this is a collision between one of your own classes and one of an external framework you are using, you can easily change the naming of your class, no big deal. But what if you use two external frameworks, both frameworks that you don't have the source to and that you can't change? Your application links with both of them and you get name conflicts. How would you go about solving these? What is the best way to work around them in such a way that you can still use both classes?
In C you can work around these by not linking directly to the library, instead you load the library at runtime, using dlopen(), then find the symbol you are looking for using dlsym() and assign it to a global symbol (that you can name any way you like) and then access it through this global symbol. E.g. if you have a conflict because some C library has a function named open(), you could define a variable named myOpen and have it point to the open() function of the library, thus when you want to use the system open(), you just use open() and when you want to use the other one, you access it via the myOpen identifier.
Is something similar possible in Objective-C and if not, is there any other clever, tricky solution you can use resolve namespace conflicts? Any ideas?
Update:
Just to clarify this: answers that suggest how to avoid namespace collisions in advance or how to create a better namespace are certainly welcome; however, I will not accept them as the answer since they don't solve my problem. I have two libraries and their class names collide. I can't change them; I don't have the source of either one. The collision is already there and tips on how it could have been avoided in advance won't help anymore. I can forward them to the developers of these frameworks and hope they choose a better namespace in the future, but for the time being I'm searching a solution to work with the frameworks right now within a single application. Any solutions to make this possible?
Prefixing your classes with a unique prefix is fundamentally the only option but there are several ways to make this less onerous and ugly. There is a long discussion of options here. My favorite is the #compatibility_alias Objective-C compiler directive (described here). You can use #compatibility_alias to "rename" a class, allowing you to name your class using FQDN or some such prefix:
#interface COM_WHATEVER_ClassName : NSObject
#end
#compatibility_alias ClassName COM_WHATEVER_ClassName
// now ClassName is an alias for COM_WHATEVER_ClassName
#implementation ClassName //OK
//blah
#end
ClassName *myClass; //OK
As part of a complete strategy, you could prefix all your classes with a unique prefix such as the FQDN and then create a header with all the #compatibility_alias (I would imagine you could auto-generate said header).
The downside of prefixing like this is that you have to enter the true class name (e.g. COM_WHATEVER_ClassName above) in anything that needs the class name from a string besides the compiler. Notably, #compatibility_alias is a compiler directive, not a runtime function so NSClassFromString(ClassName) will fail (return nil)--you'll have to use NSClassFromString(COM_WHATERVER_ClassName). You can use ibtool via build phase to modify class names in an Interface Builder nib/xib so that you don't have to write the full COM_WHATEVER_... in Interface Builder.
Final caveat: because this is a compiler directive (and an obscure one at that), it may not be portable across compilers. In particular, I don't know if it works with the Clang frontend from the LLVM project, though it should work with LLVM-GCC (LLVM using the GCC frontend).
If you do not need to use classes from both frameworks at the same time, and you are targeting platforms which support NSBundle unloading (OS X 10.4 or later, no GNUStep support), and performance really isn't an issue for you, I believe that you could load one framework every time you need to use a class from it, and then unload it and load the other one when you need to use the other framework.
My initial idea was to use NSBundle to load one of the frameworks, then copy or rename the classes inside that framework, and then load the other framework. There are two problems with this. First, I couldn't find a function to copy the data pointed to rename or copy a class, and any other classes in that first framework which reference the renamed class would now reference the class from the other framework.
You wouldn't need to copy or rename a class if there were a way to copy the data pointed to by an IMP. You could create a new class and then copy over ivars, methods, properties and categories. Much more work, but it is possible. However, you would still have a problem with the other classes in the framework referencing the wrong class.
EDIT: The fundamental difference between the C and Objective-C runtimes is, as I understand it, when libraries are loaded, the functions in those libraries contain pointers to any symbols they reference, whereas in Objective-C, they contain string representations of the names of thsoe symbols. Thus, in your example, you can use dlsym to get the symbol's address in memory and attach it to another symbol. The other code in the library still works because you're not changing the address of the original symbol. Objective-C uses a lookup table to map class names to addresses, and it's a 1-1 mapping, so you can't have two classes with the same name. Thus, to load both classes, one of them must have their name changed. However, when other classes need to access one of the classes with that name, they will ask the lookup table for its address, and the lookup table will never return the address of the renamed class given the original class's name.
Several people have already shared some tricky and clever code that might help solve the problem. Some of the suggestions may work, but all of them are less than ideal, and some of them are downright nasty to implement. (Sometimes ugly hacks are unavoidable, but I try to avoid them whenever I can.) From a practical standpoint, here are my suggestions.
In any case, inform the developers of both frameworks of the conflict, and make it clear that their failure to avoid and/or deal with it is causing you real business problems, which could translate into lost business revenue if unresolved. Emphasize that while resolving existing conflicts on a per-class basis is a less intrusive fix, changing their prefix entirely (or using one if they're not currently, and shame on them!) is the best way to ensure that they won't see the same problem again.
If the naming conflicts are limited to a reasonably small set of classes, see if you can work around just those classes, especially if one of the conflicting classes isn't being used by your code, directly or indirectly. If so, see whether the vendor will provide a custom version of the framework that doesn't include the conflicting classes. If not, be frank about the fact that their inflexibility is reducing your ROI from using their framework. Don't feel bad about being pushy within reason — the customer is always right. ;-)
If one framework is more "dispensable", you might consider replacing it with another framework (or combination of code), either third-party or homebrew. (The latter is the undesirable worst-case, since it will certainly incur additional business costs, both for development and maintenance.) If you do, inform the vendor of that framework exactly why you decided to not use their framework.
If both frameworks are deemed equally indispensable to your application, explore ways to factor out usage of one of them to one or more separate processes, perhaps communicating via DO as Louis Gerbarg suggested. Depending on the degree of communication, this may not be as bad as you might expect. Several programs (including QuickTime, I believe) use this approach to provide more granular security provided by using Seatbelt sandbox profiles in Leopard, such that only a specific subset of your code is permitted to perform critical or sensitive operations. Performance will be a tradeoff, but may be your only option
I'm guessing that licensing fees, terms, and durations may prevent instant action on any of these points. Hopefully you'll be able to resolve the conflict as soon as possible. Good luck!
This is gross, but you could use distributed objects in order to keep one of the classes only in a subordinate programs address and RPC to it. That will get messy if you are passing a ton of stuff back and forth (and may not be possible if both class are directly manipulating views, etc).
There are other potential solutions, but a lot of them depend on the exact situation. In particular, are you using the modern or legacy runtimes, are you fat or single architecture, 32 or 64 bit, what OS releases are you targeting, are you dynamically linking, statically linking, or do you have a choice, and is it potentially okay to do something that might require maintenance for new software updates.
If you are really desperate, what you could do is:
Not link against one of the libraries directly
Implement an alternate version of the objc runtime routines that changes the name at load time (checkout the objc4 project, what exactly you need to do depends on a number of the questions I asked above, but it should be possible no matter what the answers are).
Use something like mach_override to inject your new implementation
Load the new library using normal methods, it will go through the patched linker routine and get its className changed
The above is going to be pretty labor intensive, and if you need to implement it against multiple archs and different runtime versions it will be very unpleasant, but it can definitely be made to work.
Have you considered using the runtime functions (/usr/include/objc/runtime.h) to clone one of the conflicting classes to a non-colliding class, and then loading the colliding class framework? (this would require the colliding frameworks to be loaded at different times to work.)
You can inspect the classes ivars, methods (with names and implementation addresses) and names with the runtime, and create your own as well dynamically to have the same ivar layout, methods names/implementation addresses, and only differ by name (to avoid the collision)
Desperate situations call for desperate measures. Have you considered hacking the object code (or library file) of one of the libraries, changing the colliding symbol to an alternative name - of the same length but a different spelling (but, recommendation, the same length of name)? Inherently nasty.
It isn't clear if your code is directly calling the two functions with the same name but different implementations or whether the conflict is indirect (nor is it clear whether it makes any difference). However, there's at least an outside chance that renaming would work. It might be an idea, too, to minimize the difference in the spellings, so that if the symbols are in a sorted order in a table, the renaming doesn't move things out of order. Things like binary search get upset if the array they're searching isn't in sorted order as expected.
#compatibility_alias will be able to solve class namespace conflicts, e.g.
#compatibility_alias NewAliasClass OriginalClass;
However, this will not resolve any of the enums, typedefs, or protocol namespace collisions. Furthermore, it does not play well with #class forward decls of the original class. Since most frameworks will come with these non-class things like typedefs, you would likely not be able to fix the namespacing problem with just compatibility_alias.
I looked at a similar problem to yours, but I had access to source and was building the frameworks.
The best solution I found for this was using #compatibility_alias conditionally with #defines to support the enums/typedefs/protocols/etc. You can do this conditionally on the compile unit for the header in question to minimize risk of expanding stuff in the other colliding framework.
It seems that the issue is that you can't reference headers files from both systems in the same translation unit (source file). If you create objective-c wrappers around the libraries (making them more usable in the process), and only #include the headers for each library in the implementation of the wrapper classes, that would effectively separate name collisions.
I don't have enough experience with this in objective-c (just getting started), but I believe that is what I would do in C.
Prefixing the files is the simplest solution I am aware of.
Cocoadev has a namespace page which is a community effort to avoid namespace collisions.
Feel free to add your own to this list, I believe that is what it is for.
http://www.cocoadev.com/index.pl?ChooseYourOwnPrefix
If you have a collision, I would suggest you think hard about how you might refactor one of the frameworks out of your application. Having a collision suggests that the two are doing similar things as it is, and you likely could get around using an extra framework simply by refactoring your application. Not only would this solve your namespace problem, but it would make your code more robust, easier to maintain, and more efficient.
Over a more technical solution, if I were in your position this would be my choice.
If the collision is only at the static link level then you can choose which library is used to resolve symbols:
cc foo.o -ldog bar.o -lcat
If foo.o and bar.o both reference the symbol rat then libdog will resolve foo.o's rat and libcat will resolve bar.o's rat.
Just a thought.. not tested or proven and could be way of the mark but in have you considered writing an adapter for the class's you use from the simpler of the frameworks.. or at least their interfaces?
If you were to write a wrapper around the simpler of the frameworks (or the one who's interfaces you access the least) would it not be possible to compile that wrapper into a library. Given the library is precompiled and only its headers need be distributed, You'd be effectively hiding the underlying framework and would be free to combine it with the second framework with clashing.
I appreciate of course that there are likely to be times when you need to use class's from both frameworks at the same time however, you could provide factories for further class adapters of that framework. On the back of that point I guess you'd need a bit of refactoring to extract out the interfaces you are using from both frameworks which should provide a nice starting point for you to build your wrapper.
You could build upon the library as you and when you need further functionality from the wrapped library, and simply recompile when you it changes.
Again, in no way proven but felt like adding a perspective. hope it helps :)
If you have two frameworks that have the same function name, you could try dynamically loading the frameworks. It'll be inelegant, but possible. How to do it with Objective-C classes, I don't know. I'm guessing the NSBundle class will have methods that'll load a specific class.
I am wondering if the following using unit order is correct.
uses
FastMM4 in 'Fast\FastMM4\FastMM4.pas',
VCLFixPack in 'VCLFixPack.pas',
FastMove in 'Fast\FastMove\FastMove.pas',
FastCode in 'Fast\FastCode\FastCode.pas',
FastMM4Messages in 'Fast\FastMM4\FastMM4Messages.pas',
Why should I bother with the order?
There may be a few reasons:
Some units perform actions at startup. The order of such actions may be important, like FastMM4, which replaces the default memory manager with its own. This should be done before any memory is allocated.
If several units contain duplicate identifiers, the "last" one overrides the previous one. This may be on purpose, or it may be by accident. The other identifiers are still accessible, but not without qualification with the unit name.
The same as for actions at startup, actions at the end of life my be important too, and their order.
Note that it is not guaranteed that the order is preserved. If one of the units uses another, that one must be loaded first. To make a unit really the very first, make it the first in the .dpr or .dpk file.
You have three separate pieces of code here:
FastMM
VCLFixPack
FastCode
It is important to install the replacement memory manager, FastMM, before any heap allocations are performed. So I think it is clear that must be the first unit to include. And you may as well keep the two FastMM units together.
The other units make changes to the code in memory, to fix bugs (VCLFixPack) or to improve performance (FastCode). Although you have separately identified FastMove and FastCode, in reality, the FastCode unit actually installs a suite of improved functions, defined over a dozen separate separate units.
It seems quite likely that it would be important to install the VCL fixes before the VCL units are included. So VCLFixPack should appear before any VCL units.
As for FastCode, since it only influences performance, you could perfectly well use it at any point in the .dpr file. It probably does not matter if the initialization code runs with the vanilla RTL code. That said, for sake of consistency it makes sense to keep together all these units which change the behaviour of the runtime. So I would write your .dpr uses clause like this:
uses
FastMM4 in 'Fast\FastMM4\FastMM4.pas',
FastMM4Messages in 'Fast\FastMM4\FastMM4Messages.pas',
FastCode in 'Fast\FastCode\FastCode.pas',
VCLFixPack in 'VCLFixPack.pas',
....
I put FastCode before VCLFixPack because logically the RTL is at a lower level than the VCL. However, it does not matter either way around. But you've got to pick one, and that was my reasoning.
I also omitted an explicit reference to the FastMove unit. That is used by FastCode, along with a host of other units, and if you are going to omit the others, you may as well omit FastMove.
I try to clean up the models of my Rails apps by extracting repeating code into modules. I know that makes my code DRYer, but does it make my app more performant? I guess the question would be: is the code from the module loaded in memory once and for all or is it loaded every time it's included in a class? And consequently, is it advisable to include modules into ActiveRecord::Base or should they be included only in classes that need them?
As require is documented to give a different return status when told to load already loaded files, I assume that the code is only parsed once.
As to performance gains: With Java indirection is adding a penalty to method execution, which can become significant, if the method itself is small and is only found some levels of inheritance away.
On the other hand the JVM will try to turn the Java-Bytecode into Native-Bytecode, starting with the most frequently called methods. For JRuby this clearly means that methods, which are only defined once, are more likely to become optimized (early) than other methods.
I don't know the exact behavior of the Ruby-interpreter, but would assume it to also optimize more frequently called methods first.
As with any performance issue I would also assume, that there is no "this is always performing better" and individual benchmarks are needed to find the best approach for every situation.
I would advice to
do DRY programming, so you can easily adjust your code to new requirements
look at the performance of the resulting program
if you are unsatisfied with the performance (and only then)
identify often called functions and long-running functions
try to move these functions directly into the classes or rewrite in a way you generally call less functions
Including modules into classes which don't use them can become irritating and could only boost performance directly after starting the application as the may be parsed earlier. I would advice against doing so.
Today I first encountered the fishhook library https://github.com/facebook/fishhook which can be used to dynamically rebind symbols in Mach-O binaries (they say for iOS, but I guess the code will also work on OS X).
So far I only knew and used mach_override https://github.com/rentzsch/mach_override which aims at a similar goal (i.e. replacing one implementation of a function with another one), but rewrites the assembler statements of the beginning of the function to jump to a different location.
The fishhook approach looks much simpler, but since it "only" rewrites the symbol table, I have the gut feeling that it is less generic than the mach_override approach.
Can someone give some hard technical facts on situations when one project should be preferred over the other (i.e. situations where one approach won't work, but the other will)?
The two approaches use different methods:
A) fishhook works, as you have stated, on symbols in the symbol table. This means that, if a symbol is exported by a dylib or framework, and you can patch the import table, you can redirect it to your implementation.
B) mach_override uses the Mach VM APIs of OS X (and iOS) to patch the functions when they are already loaded - i.e. already in memory. It does so by binary patching the beginning of the function implementation to jump to another address (your implementation) then jump back.
Fishhook is more stable, in the sense that it is (i) an easier operation to implement and (ii) seamless once the process is loaded by dyld and the symbols are linked. However, it will not work on symbols which are not directly loaded by the executable. In other words, if you want to patch printf(3), for example, it will only work on calls to printf from your executable, and not on calls made from libSystem, or other libraries. Mach_override, however, is not all that stable, however, since it relies on certain function prologs which can be overridden - some 90% of the time, but not 100%.
While yiding is correct about iOS pages being read only, in some cases it may be possible to work around that (if you patch the executable you can also patch the LC_SEGMENT and section commands), and you can use the mach VM apis to unprotect pages (only if the device is jailbroken).
Fishhook was created for the purpose of hooking the functions which served as entry points into system calls on iOS in order to track down a rarely occurring bug. On iOS, executable pages are read only, so it's infeasible to patch in jumps, but the tables used to locate dynamically linked functions are not read only, so we patch those instead.
This approach would for obvious reasons not work for functions which are not going through an dynamic-link stub, whereas for mach_override, it would work as long as you can locate the function and write to the memory page containing the code.
Note that I have not personally used mach_override, so I'm not sure how well it actually works.
I have a c++ library which has functionality exposed to Lua, and am seeking opinions on the best ways to organise my lua code.
The library is a game engine, with a component based Game Object system. I want to be able to write some of these components as classes in Lua. I am using LuaBind, so I can do this but there are some implementation choices I must make, and would like to know how others have done it.
Should I have just one global lua_State, or one per object, one per scene, etc?
This sounds like a lot of memory overhead, but will keep everything nice and separate.
Should I have one GLOBALS table, or one per object, which can be put in place before a call to a member? This would seem to minimize the chances of some class deciding to use globals, and another accidentally overwriting it, with less memory overhead than having many lua_States.
Or should I just bung everything in the one globals table?
Another question involves the lua code ittself. Two strategies occur... Firstly shoving all class definitions in one place, loading them when the application launches, Secondly putting one class definition per file, and simply making sure that file is loaded when I need to instance it.
I'd appreciate anyone's thoughts on this, thanks.
While LuaBind is certainly very nifty and convenient, as your engine grows, so will your compile times, drastically.
If you already have, or are planning to add, a messaging system (which I heavily recommend, specially for networking), then it simplifies problems significantly. In this case, what you will need to do is simply bind a few key functions to interface with the messaging system. This will keep your compile times down, and give you a very flexible system.
Since you are doing a component based engine (Good choice BTW), It makes more sense to integrate scripting as an object component. This way, it usually makes more sense to make each scripting component a new coroutine that runs behavior for each particular object. You need not to worry about memory too much, Lua states are very light, and can be made really fast if you interface your memory manager with Lua.
If you implement scripting as a component, it is still a good idea to have global or per-level scripts loaded, (to coordinate event triggers by other objects, or maybe enemy spawning timers).
As far as loading scripts go, it would not be bad practice, to just load the scripts you will need for a level all at once, and keep them in a global table for fas accessing, loading of lua scripts is pretty fast, specially if you pre-compiled them.
One consideration is how you're planning to thread things. If you want to run the code for two Game Objects in parallel, for example, then they really ought to have their own separate lua_States so that they can both be running at the same time. (Of course, that also means that they can't really share any state, except via the C code where you'd need to be conscious of thread-safety.)
As to the Lua code, I'd recommend loading everything when the app launches (unless you really need to do "lazy" loading of your core classes on demand). It typically simplifies maintenance and debugging. And in the case of code being loaded that's no longer needed, the garbage collector will clean that up with a quickness. :-)