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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-25 17:10:33

----- Original Message -----
From: Ed Brey <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 25, 2001 6:44 PM
Subject: Re: [boost] Math constants for naive and gurus? - which constants
do you want?

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > >
> > > Of course, there is still the option of simply providing a bunch of
simple
> > double constants for non-generic uses, and then a separate simple
function
> > interface for generic uses, like this
> > >
> > > template<typename T>
> > > struct constants {}
> > >
> > > template<>
> > > struct constants<double> {
> > >     static double pi() {return 3.14;}
> > > }
> > >
> > There is a problem with this: it doesn't allow you to add new constants.
> > IMO, the design must contemplate the case of adding new constants with
as
> > much the same interface as possible.
>
> The user can add his own constants in a similar structure in his own
namespace.  He can't add them safely to the boost namespace under any
circumstance, because boost might later define something using the same
name, and there would be a conflict.
>
I see.
This is something that comes out from time to time.

If my memory isn't deceiving me, I posted about a year ago,  that, IMHO, the
framework should involve a consitent interface for every conceivable
constant, but then the 'boost namespace issue' showed up.
I suggested a simple solution: don't put the constants framework inside the
boost namespace, but in its own namespace which is documented as 'open' to
the end user (unlike the boost namespace). If, during a later release, some
new constants are added by 'boost', and they clash with those inserted
locally by the user, he/she must resolve the conflict manually, by giving
the boost names priority and allowing them to override the local ones.

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.

>  Of course, I find the concept of representing an irrational number using
a rational class kind of amusing, but I suppose it might have
> practical value.
>
Me too!

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