Subject: Re: Problem with function name net_open

From: Mark Musone <[email-masked]>
Date: Wed, 9 Sep 1998 13:06:57 -0400 (EDT)

I dont turst just an imap_ prefix.

it's too generic. the better thing to do is to also include a
vendor string somewhere, i.e. uw_imap_

i'm just thinking of the future. because of the absolutly excellent work the
Mark Crispin and everybody else at UW for making imap such an excellent standard,
soon everything will most likely be imap. 

Mark

> 
> Well.... If we're going to cause pain... 
> How 'bout prefixing everything with "imap"... ;-)
> And have an "oldnames" compatibility library...
> 
> ie:
> the real implementation of net open is:
> <return value> imap_net_open(<parameters>);
> 
> and the old names stub implementation (in a separate lib ...) is:
> <return value> net_open(<parameters>)
> {
>   return imap_net_open(<parameters>);
> }
> 
> Old clients still work (if linked with the oldnames lib) without
> recompiling.
> New clients should be written to use the new names.
> And there is no iffdef this name or that name stuff...
> 
> Opinions?? Anyone?? Bueller???
> Cheers.
> Andrew Walduck

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 Sep 1998 10:40:46 -0700 (PDT)

Before we start talking about changing function names we really should
consider:
 1) the magnitude of the problem we are trying to solve
vs.
 2) the magnitude of the problem created.

I get a "function name conflicts with such-and-such library" report about once
every 2-3 years.  Granted, empirical evidence can be misleading, but this
really suggests that (1) is considerably more minor than (2).

Also, choosing a new naming scheme has its own problems.  c-client has a much
wider scope than just IMAP; there are people who use c-client without ever
touching IMAP.  Similarly, it would be presumptious to assume that this is the
only library that will ever be written at UW.

What's really needed is some sort of library:function scoping (I can see the
C++ and other OOP guys chiming in...), but that could be done by the linker
without requiring a new language.  [Aside to the C++ and other OOP guys --
what do you do when you get object name conflicts?  Sorry...  ;-)]

For the time being, I'd argue that this problem is of academic interest only.