RE: [boost] Math constants for naive and gurus? - which constants do you want?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 09:34:02

----- Original Message -----
From: Ed Brey <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 26, 2001 9:38 AM
Subject: Re: [boost] Math constants for naive and gurus? - which constants
do you want?

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> >
> > This is actually a particular case of a more general problem with name
> > encapsulation: the politic of owning a namespace prohibiting anyone to
add
> > names in it isn't always a good design. Some frameworks are extensible
by
> > nature, and a closed namespace isn't the right place to put it.
> > IMO, it might be better to lay out a criteria for adding new names and
> > resolving the possible conflicts. In the case of constants, because of
their
> > inherent fixed nature, this scheme is unlikely to lead to inconsistent
> > program behaviour.
>
> The concept of an open framework is certainly a valid one.  It introduces
a tradeoff.  On the plus side, it allows access through a single
> interface for predefined plus users items.  On the negative side, it means
that code that worked one day may suddenly stop working, just
>because a library was upgraded, even if that library has been careful to
maintain backward compatibility.

Agreed.

> The value of the former is quite limited, since the alternative is to have
two parallel interfaces, i.e. the boost namespace and the user's
> namespace.  Using two different namespaces seems quite reasonable.

I would agree with you if in the end there were really just *two*
namespaces. Unfortunately, in my experience, this won't be the case; at
least not in the numerical applications I'm used to work with.
That is, in general -an according to my views- a numerical application
doesn't use *one* library, but a set of libraries, either layered or
independent. Following the separate namespace approach will lead to a set of
numerical constants spread along a set of namespaces, probably many.

> Plus in regions of code where many names are used from each, the using
directive can be applied and the namespace issues go away.
Right

>This reintroduces the chance of a name conflict, but notice that the extent
of the damage (i.e. resulting code changes) is limited to a given region of
code, rather than being global.
>
Right

> Unless there is some substantial benefit that can be shown to having a
single merged interface, my opinion is that the robustness of separate
namespaces is much more valuable.
>
I see.
I am not all that troubled about backward incompatibility.
I always prefered a clear scheme to resolve incompatibilities to a rigid
design.
In this case, I think that given the nature of the framework, such a scheme
can be precisely and formally defined; and would involve no more than a
search and replace on the user code.
As a library user, I'm fine if I need to change my code in order to use a
new version of the library provided that the change can be automated and is
therefore reliable.

How many times do you start using a new release of a given
library,compiler,etc... and everything worked like a charm?
I've never been that lucky :)
For example, when I switched from boost 1.24.0 to 1.25.0, I had to change
all places where I used BGL's connected_component() becuase of a small
interface change. It was so easy to figure out what the problem was and fix
it, that I even forgot to report it to boost.

Anyway, I stated the above from a user perspective.
I don't know how the general boost users would feel about this. If it turns
out that most of the users will find more anoying to have to change a
constant usage becuase it is now included in another library than to manage
the fact that the constants are in different namespaces, then I go for
separate namespaces. I'd point out, however, that IMO, the chances of
running across a conflic are a lot smaller than the chances of ending up
with a bunch of many different places were the constants are located.

BTW, here goes a really crazy idea: could we run a poll on the users list to
see what would they prefer?

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com

fo: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>