Re: [AD] namespace collision

[George Foot <gfoot@xxxxxxxxxx>]

On Tue, Aug 07, 2001 at 10:05:12PM +1000, Peter Wang wrote:
> On 06 Aug 2001, George Foot <gfoot@xxxxxxxxxx> wrote:
> > e.g. for RSXNTDJ we used to define all API variables to be
> > pointers, e.g.
> > 
> >     #define key (*key)
> > 
> > but this broke things like the DIALOG struct which also have a
> > `key' member, and function prototypes with `key' parameters.
> 
> Can you remember if there are a lot of these?
> 
> As for DIALOG.key, would changing that to something else be really
> bad?  Probably few people (if any) reference that anyway.
> 
> On the whole, I think the Mass Renaming is a good idea.

`key' crops up all over the place, but it was only a problem
before because we were changing the sense (adding the asterisk).
Renaming struct members is no problem at all, because it'll get
similarly renamed (or not, depending on whether prefixing is
enabled at the time) in both the header file and the user's
code.  struct members and tags and function parameter names are
no problem here, the only impact is on debugging symbols
generated (the debugger would call it DIALOG.allegro_key).

I can't think of any lasting problems now except for:

 a) clashes between renamed and unrenamed symbols (if two things are called 
    `this' and `allegro_this' then they'll clash with the #defines)

 b) user can't re-#define these things without being aware of the prefixing

 c) some symBols are already prefixed, which could be a little confusing

Overall I don't think these are serious at all -- (a) probably
never occurs, (b) is fairly advanced anyway, and (c) is pretty 
minor.  Here's a quick grep of allegro.h:

    already prefixed:
        allegro_id
        allegro_error
        allegro_errno
        allegro_exit
        allegro_message

    already has `allegro' (and suggested real name):
        install_allegro         => allegro_install
        find_allegro_resource   => allegro_find_resource

We could just leave those last two alone, of course.

We also need to think about what to do with new API functions in
the future -- require them to be prefixed in the API, or keep
having them auto-prefixed from short easy names by the
preprocessor.  Sort of like "using namespace allegro;". :)

George