Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
How about: _gpc_<unitname>_foo { for units } _gpc_rts_foo { for RTS stuff } _gpc_<programname>_foo { for programs }
I don't really mind, but I don't want to have to rename them again sometime later. So we should be sure the new names are "unique enough" if we rename them now.
I think that `_p_initialize' is really the main problem. Namely, it one of few (maybe the only one) rts routine with user visible name -- if `main' is in another language users should call it. And the name is really good (so good that other packages also would like to use it :).
For user names the prefix really is `_p__' so there is no conflict (at least ATM). Also, our external names look like:
_p__M3_Foo_S0_Myfun
They already include unit name (`Foo' here) and routine name (forming that names is part of qualified identifier implementation).
We may easily change the prefix (I see no reason to change the other part, it was specially designed to be unique). However, I think that change in `plotutils' is preferable:
1) We need rather large namespace and use only a single prefix 2) They use quite a lot of single letter prefixes (and polute namespace quite heavily) so quite likely they will have to change their names anyway 3) The `_' prefix was intended for language implementation. Its use in general purpose library looks like an abuse 4) Our `_p_initialize' has to be in implementation space, but is also user visible. AFAICS `plotutils' just want private names which are not intended to be user visible
BTW Has anybody contacted `plotutils' developers? (I did not).
- On many platforms one can remove conflict using linker magic.
On windows using `LoadLibrary' and `GetProcAddress' on DLL should work without conflict.
Unfortunately, I have a static version of libplot the libraries. I built it myself, and it was rather straightforward. Indeed, I propose to release the binaries sometime, since I was never able to find prebuilt Win32 binaries.
To build it into a Windows DLL with gcc would require alchemy ...
It would only be a work-around anyway.
IMHO what we are doing now (and what everbody else is doing) is really a work-around. Namely, it is linker job to integrate names from various source modules. In particular linker should have proper support for namespaces. It seems that no popular object format supports namespaces, but there is partial support: with GNU ld and ELF one can link a number of object files into a module and "localize" the symbols used internally. Similar things happen when using shared libraries.
The problem is that linker support is unportable and only partial, so everbody uses name-mangling, but I think that we need better linkers.