Boost.Conversion: functors namming
Hi, during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors. My question is what should be the name of the function that builds the functor. Some possibilities: short s=1; long l=3; using boost::phoenix::placeholders::_1; A- Use a different name: make_converter_to? s=boost::make_converter_to(*short*)(_1)(l) ; B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming). s=boost::conversion::fp::convert_to(*short*)(_1)(l) ; C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter. s=boost::convert_to(*short*)(_1)(l) ; Which are your preferences? Best, Vicente
Vicente BOTET wrote:
during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors.
My question is what should be the name of the function that builds the functor. Some possibilities:
short s=1; long l=3; using boost::phoenix::placeholders::_1;
A- Use a different name: make_converter_to?
s=boost::make_converter_to(*short*)(_1)(l) ;
B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming).
s=boost::conversion::fp::convert_to(*short*)(_1)(l) ;
C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter.
s=boost::convert_to(*short*)(_1)(l) ;
Your examples hide the functors, which somewhat obscures your request, I think, unless I've missed something. That is, I think you're asking what to name "factory" in the following example: auto f(factory<short>(_1)); short const s(f(static_cast<long>(3))); Your suggestions for the "factory" call are: A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1) I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Vicente BOTET wrote:
during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors.
My question is what should be the name of the function that builds the functor. Some possibilities:
short s=1; long l=3; using boost::phoenix::placeholders::_1;
A- Use a different name: make_converter_to?
s=boost::make_converter_to(*short*)(_1)(l) ;
B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming).
s=boost::conversion::fp::convert_to(*short*)(_1)(l) ;
C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter.
s=boost::convert_to(*short*)(_1)(l) ;
Your examples hide the functors, which somewhat obscures your request, I think, unless I've missed something. That is, I think you're asking what to name "factory" in the following example:
auto f(factory<short>(_1)); short const s(f(static_cast<long>(3)));
Your suggestions for the "factory" call are:
A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1)
Yes. You have understood my request.
I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda.
Even if C is the more elegant, to my taste, it introduce a dependency on Boost.Phonix even if functors are not used, and this is one thing I would like to avoid. So it seems that A is a best compromise. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet wrote:
Stewart, Robert wrote:
auto f(factory<short>(_1)); short const s(f(static_cast<long>(3)));
Your suggestions for the "factory" call are:
A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1)
I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda.
Even if C is the more elegant, to my taste, it introduce a dependency on Boost.Phonix even if functors are not used, and this is one thing I would like to avoid. So it seems that A is a best compromise.
That overload can be put into a separate header so it, and its dependency on Phoenix, is only visible when desired. <boost/conversion/functor.hpp>? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Vicente Botet wrote:
Stewart, Robert wrote:
auto f(factory<short>(_1)); short const s(f(static_cast<long>(3)));
Your suggestions for the "factory" call are:
A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1)
I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda.
Even if C is the more elegant, to my taste, it introduce a dependency on Boost.Phonix even if functors are not used, and this is one thing I would like to avoid. So it seems that A is a best compromise.
That overload can be put into a separate header so it, and its dependency on Phoenix, is only visible when desired. <boost/conversion/functor.hpp>?
Hi, this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders. Let me know if I'm missing something. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, May 25, 2011 at 10:44 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Stewart, Robert wrote:
Vicente Botet wrote:
Stewart, Robert wrote:
auto f(factory<short>(_1)); short const s(f(static_cast<long>(3)));
Your suggestions for the "factory" call are:
A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1)
I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda.
Even if C is the more elegant, to my taste, it introduce a dependency on Boost.Phonix even if functors are not used, and this is one thing I would like to avoid. So it seems that A is a best compromise.
That overload can be put into a separate header so it, and its dependency on Phoenix, is only visible when desired. <boost/conversion/functor.hpp>?
Hi,
this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders.
Let me know if I'm missing something.
FWIW, a phoenix actor is a concept, yes. The file boost/phoenix/core/is_actor.hpp has only a dependency on the boost/mpl/bool.hpp header. So including this might not really add to much dependency on your code. Another possibility certainly is to create your own trait: template <typename T, typename Enable> struct enable_functor : mpl::false_ {}; or something, that gets specialized on phoenix::is_actor once your user includes the header that enables functors. Using this, you gain another point of flexibility by being able to support other functional style libraries.
Best, Vicente
-- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thomas Heller-7 wrote:
On Wed, May 25, 2011 at 10:44 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Stewart, Robert wrote:
Vicente Botet wrote:
Stewart, Robert wrote:
auto f(factory<short>(_1)); short const s(f(static_cast<long>(3)));
Your suggestions for the "factory" call are:
A. boost::make_converter_to<short>(_1) B. boost::conversion::fp::convert_to<short>(_1) C. boost::convert_to<short>(_1)
I definitely dislike B. A isn't bad, but it should be in the boost::conversion namespace. C is very nice, but it should be in the boost::conversion namespace. The introduction of the placeholder is enough to signal that the result is a Phoenix lambda.
Even if C is the more elegant, to my taste, it introduce a dependency on Boost.Phonix even if functors are not used, and this is one thing I would like to avoid. So it seems that A is a best compromise.
That overload can be put into a separate header so it, and its dependency on Phoenix, is only visible when desired. <boost/conversion/functor.hpp>?
Hi,
this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders.
Let me know if I'm missing something.
FWIW, a phoenix actor is a concept, yes. The file boost/phoenix/core/is_actor.hpp has only a dependency on the boost/mpl/bool.hpp header. So including this might not really add to much dependency on your code.
Another possibility certainly is to create your own trait:
template <typename T, typename Enable> struct enable_functor : mpl::false_ {};
or something, that gets specialized on phoenix::is_actor once your user includes the header that enables functors. Using this, you gain another point of flexibility by being able to support other functional style libraries.
Thanks for your clever suggestion. I will adopt it. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet wrote:
Thomas Heller-7 wrote:
On Wed, May 25, 2011 at 10:44 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Hi,
this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders.
Let me know if I'm missing something.
FWIW, a phoenix actor is a concept, yes. The file boost/phoenix/core/is_actor.hpp has only a dependency on the boost/mpl/bool.hpp header. So including this might not really add to much dependency on your code.
Another possibility certainly is to create your own trait:
template <typename T, typename Enable> struct enable_functor : mpl::false_ {};
or something, that gets specialized on phoenix::is_actor once your user includes the header that enables functors. Using this, you gain another point of flexibility by being able to support other functional style libraries.
Thanks for your clever suggestion. I will adopt it.
Well it seems it is to clever to me. I don't reach to specialize enable_functor for a T satisfying phoenix::is_actor. BTW,what is the Enabled parameter for? How this metafunction could be used? Any help would appreciated. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Wed, May 25, 2011 at 2:28 PM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Vicente Botet wrote:
Thomas Heller-7 wrote:
On Wed, May 25, 2011 at 10:44 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Hi,
this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders.
Let me know if I'm missing something.
FWIW, a phoenix actor is a concept, yes. The file boost/phoenix/core/is_actor.hpp has only a dependency on the boost/mpl/bool.hpp header. So including this might not really add to much dependency on your code.
Another possibility certainly is to create your own trait:
template <typename T, typename Enable> struct enable_functor : mpl::false_ {};
or something, that gets specialized on phoenix::is_actor once your user includes the header that enables functors. Using this, you gain another point of flexibility by being able to support other functional style libraries.
Thanks for your clever suggestion. I will adopt it.
Well it seems it is to clever to me. I don't reach to specialize enable_functor for a T satisfying phoenix::is_actor. BTW,what is the Enabled parameter for? How this metafunction could be used?
Any help would appreciated.
The Enable template parameter was exactly to specialize for phoenix actors ;) template <typename T, typename Enable = void> struct is_lazy : mpl::false_ {}; template <typename T> struct is_lazy<T, typename enable_if<is_actor<T> >::type > : mpl::true_ {}; HTH, Thomas
Thomas Heller-7 wrote:
On Wed, May 25, 2011 at 2:28 PM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Vicente Botet wrote:
Thomas Heller-7 wrote:
On Wed, May 25, 2011 at 10:44 AM, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Hi,
this independent overloading could be done if there was a class placeholder, but in Phoenix a placeholder is a concept, isn't it. So the overloading can be done only using SFINAE, which implies that one overload works for T that are placeholders and the otherfor T that are no placeholders.
Let me know if I'm missing something.
FWIW, a phoenix actor is a concept, yes. The file boost/phoenix/core/is_actor.hpp has only a dependency on the boost/mpl/bool.hpp header. So including this might not really add to much dependency on your code.
Another possibility certainly is to create your own trait:
template <typename T, typename Enable> struct enable_functor : mpl::false_ {};
or something, that gets specialized on phoenix::is_actor once your user includes the header that enables functors. Using this, you gain another point of flexibility by being able to support other functional style libraries.
Thanks for your clever suggestion. I will adopt it.
Well it seems it is to clever to me. I don't reach to specialize enable_functor for a T satisfying phoenix::is_actor. BTW,what is the Enabled parameter for? How this metafunction could be used?
Any help would appreciated.
The Enable template parameter was exactly to specialize for phoenix actors ;)
Thanks, this is working now. Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/5/15 Vicente BOTET <vicente.botet@wanadoo.fr>
Hi,
during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors.
My question is what should be the name of the function that builds the functor. Some possibilities:
short s=1; long l=3; using boost::phoenix::placeholders::_1;
A- Use a different name: make_converter_to?
s=boost::make_converter_to(*short*)(_1)(l) ;
B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming).
s=boost::conversion::fp::convert_to(*short*)(_1)(l) ;
Proto uses a separate namespace boost::proto::functional for such, so I think it's OK for Convert as well, while 'sp' is being too succinct, I think it'd be better to leave such tiny naming for the users themselves. If 'functional' is too long, maybe 'lazy' is a good choice...If this is your decision.
C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter.
Maybe it's just a simple overloading without SFINAE. But this may imply that it's tied to Phoenix actor...
TONGARI wrote:
2011/5/15 Vicente BOTET <vicente.botet@wanadoo.fr>
Hi,
during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors.
My question is what should be the name of the function that builds the functor. Some possibilities:
short s=1; long l=3; using boost::phoenix::placeholders::_1;
A- Use a different name: make_converter_to?
s=boost::make_converter_to(*short*)(_1)(l) ;
B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming).
s=boost::conversion::fp::convert_to(*short*)(_1)(l) ;
Proto uses a separate namespace boost::proto::functional for such, so I think it's OK for Convert as well, while 'sp' is being too succinct, I think it'd be better to leave such tiny naming for the users themselves.
If 'functional' is too long, maybe 'lazy' is a good choice...If this is your decision.
Yes functional will be better than fp.
C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter.
Maybe it's just a simple overloading without SFINAE. But this may imply that it's tied to Phoenix actor... Yes, this is a major drawback. Tanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-functors-namming-tp35240... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (5)
-
Stewart, Robert -
Thomas Heller -
TONGARI -
Vicente Botet -
Vicente BOTET