Extension methods c++0x
german diago
proposal for c#-like extension methods. Extension methods let
programmers write new methods and use it as if they were class methods
from outside the class. I know it's sintactic sugar, but it makes code
far more readable. As an example:
string str = " hello , world !!!";
to_upper(split(trim_left(str), '<')[0]));
could be written as
str.trim_left().split('<')[0].to_upper();
This way reading of the code is far easier, because you can read from
left to right and you inmediatly know what the code means. In the
other case, you have to read code from inside to outside. In my
experience the second thing is easier, it fits better my mental model.
What I say is not based on a guess. I usually write code in python
managing strings with algorithms using things like above. When I try
to translate them to c++, I see that it requires much more thought
than what could be required.
When I see python and see how easy is to write code for it, specially
string algorithms, I wonder why not
to be able to write extension methods similar to the [:] python
operator and extension methods like
above. Programming is all about making tools that fit our mental
model, no mental models that fit our tools.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Francis Glassborow
> Hello. I've been reading c++0x proposals and I'd like to see a
> proposal for c#-like extension methods. Extension methods let
> programmers write new methods and use it as if they were class methods
> from outside the class. I know it's sintactic sugar, but it makes code
> far more readable. As an example:
Sorry, but you are wasting your time because we have already had to
postpone much more important proposals to a TR or a Normative addendum
so that we have a fighting chance of delivering the new standard in a
timely fashion. The door shut on new proposals (much) more than a year ago
Felipe Magno de Almeida
> Hello. I've been reading c++0x proposals and I'd like to see a
> proposal for c#-like extension methods. Extension methods let
> programmers write new methods and use it as if they were class methods
> from outside the class. I know it's sintactic sugar, but it makes code
> far more readable. As an example:
>
> string str = " hello , world !!!";
>
> to_upper(split(trim_left(str), '<')[0]));
>
> could be written as
>
> str.trim_left().split('<')[0].to_upper();
[snip]
Though now impossible to make to C++0X, this proposal seem to have
merit. Maybe you could write something for boost? ;)
Maybe even changing it to use operator overloading instead of member
functions? This would greatly increase extensability.
str <= (trim_left() >> split('<'))[0] >> to_upper();
This looks a little like spirit, but for in-place string
manipulations.
Regards,
--
Felipe Magno de Almeida
Andre Kaufmann
> german diago wrote:
>> Hello. I've been reading c++0x proposals and I'd like to see a
> timely fashion. The door shut on new proposals (much) more than a year ago
>
Won't there be another standard in the future after the upcoming one ?
Or isn't there currently no time to discuss future proposals ?
Andre
James Dennett
> Francis Glassborow schrieb:
>> german diago wrote:
>>> Hello. I've been reading c++0x proposals and I'd like to see a
>> [...]
>> timely fashion. The door shut on new proposals (much) more than a year
>> ago
>>
>
> Won't there be another standard in the future after the upcoming one ?
It's very likely that there will.
> Or isn't there currently no time to discuss future proposals ?
Indeed, those most involved with C++0x don't have much, if any,
time to devote to C++1x at the present time. It might help for
others, though, if you clearly note when proposing changes that
you are suggesting them for *after* C++0x, to pre-empty people
pointing out that you are indeed too late for C++0x.
-- James
Francis Glassborow
> Francis Glassborow schrieb:
>> german diago wrote:
>>> Hello. I've been reading c++0x proposals and I'd like to see a
>> [...]
>> timely fashion. The door shut on new proposals (much) more than a year
>> ago
>>
>
> Won't there be another standard in the future after the upcoming one ?
Yes but being composed of human beings the C++ Standards Committees have
to keep focused on the current work. When that has been delivered will
be the time to consider anything more.
> Or isn't there currently no time to discuss future proposals ?
>
Yes. In addition we already have a substantial amount of work already
scheduled for after delivery of C++0x. Such things as modules are high
on the priorities of quite a few of us.
german diago
wrote:
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
A first very preliminar implementation is here. The idea is to be able
to wrap algorithms so that they work
with operator- for certain classes. This is a proof of concept. Take a
look at the code. I have some problems. Please read
the comments in the code and if anyone can help... Thanks!!
#include <string>
#include <boost/algorithm/string.hpp>
#include <boost/function.hpp>
#include <iostream>
#include <vector>
//I want this function to return an arbitrary type
template <class klass, class UnaryFunction>
klass &
operator-(klass & object, UnaryFunction f)
{
return f(object);
}
//but if I do like this:
//template <class ResultType, class klass, class UnaryFunction>
//RetType & operator-(klass & object, UnaryFunction f)
//{
// return f(object);
//}
//The function above is not found. It finds another overload instead
of this.
//I'd like to be able to return anything. I can't use boost::enable_if
for overloading
//because operator- must take 1 or 2 arguments. Found a solution? Tell
me.
struct trim_left
{
std::string & operator()(std::string & str)
{
boost::trim_left(str);
return str;
}
};
//Simplified a lot. Proof of concept.
struct split
{
const char * c_;
split(const char * c) : c_(c) {}
std::vector<std::string> operator()(std::string & str)
{
std::vector<std::string> vec;
boost::split(vec, str, boost::is_any_of(c_));
return vec;
}
};
//Macros to extend classes with certain algorithms. This will generate
the boilerplate code above.
//The library will be used with these macros.
#define EXTENSION_METHOD(classextended, algorithm) //TODO
#define EXTENSION_METHOD1(classextended, algorithm, arg1type) //TODO
#define EXTENSION_METHOD2(classextended, algorithm, arg1type,
arg2type) //TODO
//An example!!!
int main()
{
std::string str = " Hello, world!!!";
//This works!!!
str-trim_left();
//This one does not work. The return type for split is a vector (to
simplify, at this moment)
//But I can't overload operator-
//str-trim_left()-split("<");
std::cout << str << std::endl;
german diago
> on the priorities of quite a few of us.
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
Modules is the only single proposal I wish it had been accepted for
the next standard.
Anyway, I think that extension methods would be a good proposal,
although not for C++0x.
It's a pitty.
I think extension methods is a very little extension to the language
compared to, say, modules and concepts.
shunsuke
> Hello. I've been reading c++0x proposals and I'd like to see a
> proposal for c#-like extension methods. Extension methods let
> programmers write new methods and use it as if they were class methods
> from outside the class. I know it's sintactic sugar, but it makes code
> far more readable. As an example:
>
> string str = " hello , world !!!";
>
> to_upper(split(trim_left(str), '<')[0]));
>
> could be written as
>
> str.trim_left().split('<')[0].to_upper();
FWIW, there is an emulation in C++98:
http://p-stade.sourceforge.net/oven/index.html
Oven makes use of `operator|`.
Regards,
--
Shunsuke Sogame
Yechezkel Mett
> On 23 dic, 20:19, Felipe Magno de Almeida <felipe.m.alme...@gmail.com>
> wrote:
> > On Dec 22, 3:38 pm, german diago <germandi...@gmail.com> wrote:
> >
> > > Hello. I've been reading c++0x proposals and I'd like to see a
> > > proposal for c#-like extension methods. Extension methods let
> > > programmers write new methods and use it as if they were class methods
> > > from outside the class. I know it's sintactic sugar, but it makes code
> > > far more readable. As an example:
> >
> > > string str = " hello , world !!!";
> >
> > > to_upper(split(trim_left(str), '<')[0]));
> >
> > > could be written as
> >
> > > str.trim_left().split('<')[0].to_upper();
> >
> > Maybe even changing it to use operator overloading instead of member
> > functions? This would greatly increase extensability.
> >
> > str <= (trim_left() >> split('<'))[0] >> to_upper();
> A first very preliminar implementation is here. The idea is to be able
> to wrap algorithms so that they work
> with operator- for certain classes.
Using operator- seems a bad idea, but for a proof of concept I suppose
it's ok.
> This is a proof of concept. Take a
> look at the code. I have some problems. Please read
> the comments in the code and if anyone can help... Thanks!!
>
> #include <string>
> #include <boost/algorithm/string.hpp>
> #include <boost/function.hpp>
> #include <iostream>
> #include <vector>
>
> //I want this function to return an arbitrary type
> template <class klass, class UnaryFunction>
> klass &
> operator-(klass & object, UnaryFunction f)
> {
> return f(object);
> }
An unconstrained template operator? That seems a very bad idea.
> //but if I do like this:
> //template <class ResultType, class klass, class UnaryFunction>
> //RetType & operator-(klass & object, UnaryFunction f)
> //{
> // return f(object);
> //}
> //The function above is not found. It finds another overload instead
> of this.
> //I'd like to be able to return anything. I can't use boost::enable_if
> for overloading
> //because operator- must take 1 or 2 arguments. Found a solution? Tell
> me.
You can use enable_if on the return value, but that won't help you
here. The problem is that the compiler has no way of deducing what
RetType is. (It won't look in the definition for deduction.) Have a
look at (boost/tr1)::result_of. A better resolution will be decltype,
but that isn't generally available yet.
I would suggest writing a separate operator- for each function type.
You will then have another problem: your operator- takes a non-const
reference as its first parameter, but you're going to need to pass an
rvalue to it. Since rvalue-references are not yet generally available,
your best bet may be to take a const reference. Perhaps overload on
const.
Yechezkel Mett
Pavel Vozenilek
"german diago" wrote:
> Hello. I've been reading c++0x proposals and I'd like to see a
> proposal for c#-like extension methods. Extension methods let
> programmers write new methods and use it as if they were class methods
> from outside the class. I know it's sintactic sugar, but it makes code
> far more readable. As an example:
>
> string str = " hello , world !!!";
>
> to_upper(split(trim_left(str), '<')[0]));
>
> could be written as
>
> str.trim_left().split('<')[0].to_upper();
>
If only methods accociated with a class will be enough for you
(not methods associated with an individual instance)
then a library based solution exists:
http://tech.groups.yahoo.com/group/boost/files/polymorphic_map/
(Yahoo groups account required).
It allows to associate any data (including functors) with any data type
and it can handle class hierarchies.
/Pavel
german diago
proposal for c#-like extension methods. Extension methods let
programmers write new methods and use it as if they were class methods
from outside the class. I know it's sintactic sugar, but it makes code
far more readable. As an example:
string str = " hello , world !!!";
to_upper(split(trim_left(str), '<')[0]));
could be written as
str.trim_left().split('<')[0].to_upper();
This way reading of the code is far easier, because you can read from
left to right and you inmediatly know what the code means. In the
other case, you have to read code from inside to outside. In my
experience the second thing is easier, it fits better my mental model.
What I say is not based on a guess. I usually write code in python
managing strings with algorithms using things like above. When I try
to translate them to c++, I see that it requires much more thought
than what could be required.
When I see python and see how easy is to write code for it, specially
string algorithms, I wonder why not
to be able to write extension methods similar to the [:] python
operator and extension methods like
above. Programming is all about making tools that fit our mental
model, no mental models that fit our tools.
---
Martin
<francis.glassbo...@btinternet.com> wrote:
> Sorry, but you are wasting your time because we have already had to
> postpone much more important proposals to a TR or a Normative addendum
> so that we have a fighting chance of delivering the new standard in a
> timely fashion. The door shut on new proposals (much) more than a year ago
Didn't you submit a proposal for extension methods a long time ago?
It was called something like "uniform calling syntax".
What happened to it?
Francis Glassborow
> On 22 Dec 2007, 23:07, Francis Glassborow
> <francis.glassbo...@btinternet.com> wrote:
>> Sorry, but you are wasting your time because we have already had to
>> postpone much more important proposals to a TR or a Normative addendum
>> so that we have a fighting chance of delivering the new standard in a
>> timely fashion. The door shut on new proposals (much) more than a year ago
>
> Didn't you submit a proposal for extension methods a long time ago?
> It was called something like "uniform calling syntax".
>
> What happened to it?
>
Yes but much of what it was designed to achieve is provided by concept maps.