I am building up a library of my own shared code and wish to create EUnit tests for that shared code. However, EUnit takes a dependency on Sugar which results in name collisions with some of the classes in my shared code.
This means I either have to adopt prefixes or some other explicit strategy (such as choosing less intuitive/more awkward names for the classes involved) to avoid those name collisions in my code (since it is the late-comer to the class naming party) or abandon the idea of using EUnit as the platform for my tests.
Neither is particularly appealing. To say the least.
The Fly in the Ointment
As I understand it, the underlying problem is the lack of proper namespace support in Objective-C. Public classes (etc) are required to have unique names in NOUGAT projects. There is a reference in the documentation site to the use of name mangling to avoid collisions, but this (I presume) proved too complex/fragile since this is not actually the case (for public names).
However, I wonder if this might now also be extended to public names as well, now that we have shared code projects ?
When building an application target any public names in the application are never-the-less private to the application even if they are public within it. i.e. name mangling could surely be used to ensure that application declared class names do not collide with any names in frameworks or libraries referenced by the application. Those referenced libraries and frameworks by definition are not referencing the application defined names so won’t care if they are being mangled. There won’t be any collisions.
It remains the case that when building a framework or library, public names must be unique and mangling cannot be reliably employed to ensure this (or becomes unacceptably complex/fragile) due to the fact that the library or framework will or may be consumed by other projects (be they applications or other libraries/frameworks).
Prior to Shared Code projects then, the primary means of creating re-usable code was via libraries, which precluded the use of public name mangling.
However, with Shared Code projects it is now possible to have code that is shared by potentially many applications which is not part of any library, instead being compiled as part of each application itself.
It occurs to me that in these cases, since my code is being compiled into an application, not a shared library, the compiler should be able to mangle names to avoid those collisions on my behalf, automatically. It should not (cannot) do so building a library target. But this would seem to me to be an acceptable trade-off:
Building a library: No public name mangling. Public names must be explicitly unique (the current situation)
Building an application: Public names are automatically mangled for uniqueness by the compiler, as for non-public names.
If your objective is to create a re-usable library and you know that one of your targets is/will/may be an Objective-C framework then you must take this into account in the public names in your library design (and it perhaps would be advisable to follow the accepted practices in this respect - i.e. explicitly prefixed class names).
But if you are using shared code projects as the vector for sharing code between applications then this need not be an issue or a concern when building those applications.
Need it ?