Namespace policy: putting names in boost::detail

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Namespace policy: putting names in boost::detail

Mathias Gaunard-2
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Vicente Botet
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.

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

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

Mathias Gaunard-2
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Robert Ramey
In reply to this post by Mathias Gaunard-2
Mathias Gaunard 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.
>

I think we want to move away from including anything
in boost::detail.  Consider making you're "sublibrary" as

boost::smid::sublibrary.

Should the sublibrary attract wider interest so it
might be considered promotion, all you'll have to do
is do a global replace boost::smid::sublibrary <- boost::sublibrary.
In fact, if you've used "using" judiciously in your code
even that would be trivial.

Robert Ramey





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Rene Rivera-2
On 7/4/2011 1:54 PM, Robert Ramey wrote:
> Mathias Gaunard 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?
>
> I think we want to move away from including anything
> in boost::detail.  Consider making you're "sublibrary" as
>
> boost::smid::sublibrary.
>
> Should the sublibrary attract wider interest so it
> might be considered promotion, all you'll have to do
> is do a global replace boost::smid::sublibrary<- boost::sublibrary.
> In fact, if you've used "using" judiciously in your code
> even that would be trivial.

+1


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Mathias Gaunard-2
In reply to this post by Robert Ramey
On 07/04/2011 08:54 PM, Robert Ramey wrote:

> In fact, if you've used "using" judiciously in your code
> even that would be trivial.

That doesn't work to inject overloads and specializations.

namespace A
{
     template<class T>
     struct foo;
}

namespace B
{
     using A::foo;
     template<> struct foo<int> {};
}

does not work.

The implementation detail in question is a generalized concept-based
overloading system, and it requires all overloads and specializations to
be in the same namespace.

I guess I'll just put it in boost::simd::detail and hide its uage behind
a macro.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Vicente Botet
In reply to this post by Mathias Gaunard-2
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.

Best,
Vicente
Reply | Threaded
Open this post in threaded view
|

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

Thomas Heller-7
On Tue, Jul 5, 2011 at 7:40 AM, Vicente Botet <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost