Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 1 Apr 2010 14:16:34 -0600

> Would a second-level tag "com" (or "libcom"?) make 
> sense for all libcom stuff, and then maybe "osi" 
> below that?

This of course comes down to the question of whether the namespace should be partitioned on packaging boundaries, in addition to functional boundaries. I don’t claim to have a lot of experience with designing c++ namespace hierarchies. I suppose the rationale against including packaging boundaries in the namespace hierarchy would be that you couldn’t change the packaging without impacting the source code of users. Is there a benefit resulting from including packaging boundaries in the namespace hierarchy?

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

> -----Original Message-----
> From: Ralph Lange [mailto:[email protected]]
> Sent: Thursday, April 01, 2010 1:15 PM
> To: Jeff Hill
> Cc: 'EPICS core-talk'
> Subject: Re: naming the operating system independence layer
> 
> If I remember correctly,
> the problem was having an "osi" prefix in the global namespace (which
> actually might collide with other libraries), when we decided that all
> epics-related libcom stuff should rather prefix everything with "epics"
> - be it osi or not.
> 
> I don't think there will be any objections against "osi" inside "epics".
> 
> Would a second-level tag "com" (or "libcom"?) make sense for all libcom
> stuff, and then maybe "osi" below that?
> 
> Ralph
> 
> 
> On Thu 01 Apr 2010 14:12:29 Jeff Hill wrote:
> >> I agree with the others, the namespace epics::osi should be well-
> >> recognized within this community, I see no reason to change it.
> >>
> >
> > The namespace "epics::osi" is definitely not well recognized within the
> > community because I created it last fall on the CVS main trunk. It
> isn’t in
> > any released version of the software.
> >
> > During the design of R3.14 and R3.13 I used "osi" embedded in the
> global
> > names of many operating system independent C functions. I needed such
> > functions earlier because the CA client library was portable almost
> from the
> > beginning. At some point during the port of the IOC to other OS "osi"
> was
> > removed from many operating systems independent interfaces in favor of
> > "epics" according to popular decision at an APS meeting. Some C
> functions
> > retain "osi" in their names today because I just didn’t have time to
> change
> > everything. There were no namespaces at that time; we did not favor
> using
> > them because of portability concerns with certain archaic vxWorks
> compilers.
> > Those compilers are probably 15 years old; so perhaps namespaces are
> > appropriate now. With the advent of c++ namespaces in EPICS we must
> choose
> > wisely. Perhaps we will decide that putting most functions in an
> "epics"
> > namespace is now a good idea. Nevertheless, after some careful thought
> > perhaps all will conclude that this "epics" namespace would need to be
> > partitioned, and so one is led to the idea of "epics :: osi" or perhaps
> > alternatively "epics :: osl" or "epics :: ???" for operating system
> > independent interfaces. Personally "epics :: osi" does not bother me. I
> am
> > suffering from the impression that the APS developers didn’t like the
> name
> > "osi" and so I was attempting to find a compromise name using an
> appropriate
> > review process.
> >
> > Thanks for your contemplation,
> >
> > Jeff
> > ______________________________________________________
> > Jeffrey O. Hill           Email        [email protected]
> > LANL MS H820              Voice        505 665 1831
> > Los Alamos NM 87545 USA   FAX          505 665 5107
> >
> > Message content: TSPA
> >
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System