Re: [boost] Namespace policy: putting names in boost::detail

Subject: Re: [boost] Namespace policy: putting names in boost::detail
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-07-05 04:39:02

On Tue, Jul 5, 2011 at 7:40 AM, Vicente Botet <vicente.botet_at_[hidden]> wrote:
>
> Mathias Gaunard-2 wrote:
>>
>> On 04/07/2011 18:53, Vicente Botet wrote:
>>>
>>> Mathias Gaunard-2 wrote:
>>>>
>>>> A GSoC student and I are currently converting a library to use the
>>>> namespace boost::simd.
>>>>
>>>> Some of the implementation details of the library are not simd-specific,
>>>> and we would like to use them in some other libraries that extend
>>>> boost::simd.
>>>>
>>>> Would it be ok to put them in the boost::detail namespace, or is that
>>>> considered as bad as putting stuff in the boost namespace?
>>>>
>>>> We need to inject overloads and specializations into a unique namespace
>>>> for boost.simd and NT2, so we could need two names, like
>>>> boost::detail::dispatch and boost::detail::specialize.
>>>>
>>>>
>>>
>>> What kind of dispatch and specializations do you need to share that they
>>> can
>>> not be on simd? Maybe some more context will help.
>>
>> NT2 and Boost.SIMD use a fully externalizable function dispatching and
>> specialization mechanism.
>>
>> In NT2, we have some functions, like plus, multiplies, etc. that work on
>> a variety of types: scalars, simd packs, expression trees, tables,
>> matrices, polynoms, etc.
>> Each function can thus be specialized many times, some times just for
>> particular scalars or simd pack types for example.
>> All specializations of all functions are provided as specializations of
>> the same class.
>>
>> The dispatching uses overloading to select the best specialization
>> available using partial ordering.
>> It already relies on ADL tricks so I don't think we can be very flexible
>> with regards to namespaces.
>>
>> Boost.SIMD will only contain the scalar and simd packs specializations,
>> and we would need to add the other versions of NT2.
>>
>> Actually, I think it might be better to put all that in the namespace
>> boost::detail::dispatch (or even boost::dispatch), as some kind of
>> "pending" library
>>
>>
>
> I don't know if this can be used by the user as an extension mechanism in
> your case, but if it is the case, the namespace should be public.

I agree, when its supposed to be something a user is supposed to customize,
it, imho, doesn't make a lot of sense to put into a detail namespace. Besides
my understanding of "implementation detail" is that its supposed to be able to
be changed without further notification and without disrupting already existing
user code depending on that.
It would have to be documented at least, and putting it along with other
implementation details, that are never documented and subject to change, doesn't
make a lot of sense to me.

Just my 0.02€

Regards,
Thomas