Decide between . operator and operator >> or a design that supports both. about rxcpp

For C++, I'm personally a fan of operator >> with free functions, but it does involve the most compiler resource overhead and library writer overhead. E.g.:

std::vector<int> v;
v >> linq::select([](x) { return x * 2; });

I think a good template-file code generator could take the work out of generating all the linq operators. Free functions offer the most flexibility as far as Koenig lookup allows. I assume that's what you meant by operator<<?

[furuholm]

When I did some testing the compiler was not able to deduce the type of the input parameter to select. The best I could produce come up with was:

v >> linq::select([](int x) { return x * 2; });

I don't have the code right here but I can provide it later if you want to see what I did.

C++ doesn't have a feature for detecting input arguments to a lambda. They have to be explicitly named. Also, due to shortsightedness in the design of the lambda feature, on most compilers you have to specifically say the type of the lambda argument too. E.g.:

v >> linq::select([](int x){ return x * 2; });

I've heard from multiple compiler designers that the compilers already could infer the type of the function argument, but speculate that no compiler implements it for fear of being incompatible with a future standard correcting the issue.

On the other hand, the boost::lambda library can infer argument types, but only for simple expressions -- it's really just an awesome hack:

v >> linq::select(_1 * 2);

[kirkshoop]

I have both syntaxes working with the same code, in my experimental branch (https://rxcpp.codeplex.com/SourceControl/network/forks/kirkshoop/rxcpp?branch=static_observer_experiment)

Due to the fact that the operator >> pattern requires late binding of the source to the rx operator, the construction of each rx operator sends all its parameters through a couple more function calls and moves. Otherwise the code produced is the same.

Using operator >>
The repeated rxo:: namespace references are demotivating for me. But reopening the rxcpp::operators namespace makes it easier to promote the visibility of externally defined operators.

    auto s = rx::observable<>::range(1, 100, 1)
        >> rxo::filter(IsPrime)
        >> rxo::subscribe([](int t) {
            const auto prime = IsPrime(t) ? t : -1;
            REQUIRE( t == prime );
        });

Using member functions
I am going to start playing with ways to inject external operator functions to observable

    auto s = rx::observable<>::range(1, 100, 1)
        .filter(IsPrime)
        .subscribe([](int t) {
            const auto prime = IsPrime(t) ? t : -1;
            REQUIRE( t == prime );
        });

[furuholm]

Excellent!

Regarding the rxo namespace: I think it looks fine. It's up to the user to do whatever works for him/her.

I would prefer range to be a free function rather than a static member function of observable. Especially if you take the operator >> route (which I think looks very promising!)

I like the rx namespace! Maybe a switch from rxcpp to rx would be in order? If you find yourself wondering if you are using c++ or not I guess you have bigger issues :)

Is it ok to open tickets with suggestions like the namespace name change?

[furuholm]

Fixed a few build issues for clang but I wasn't able to send a pull request to your fork on CodePlex (wasn't able to fork your fork). It's here anyways: https://rxcpp.codeplex.com/SourceControl/network/forks/furuholm/rxcpp?branch=static_observer_experiment

[kirkshoop]

Glad you like it.

Please do open tickets for suggestions like these.

Adding a range free function in the rxs namespace is easy. Feel free to add it.

My response to having rx as the real namespace is that it is too short. I do not want anyone to curse about how the rx class in their project conflicted with the namespace. I believe that namespaces are supposed to be unique. shortening them should be done with an alias in each project.

I can be persuaded that the namespace should omit the cpp redundancy. I am trying to make rxcpp the unique identifier in the larger Rx community, but in the project we could use namespace ReactiveExtensions. Sadly though it would make the compiler and debugger display of symbols even more noisy than it is. maybe a name somewhere between..

[kirkshoop]

Sorry it took so long. I merged your changes for clang into my fork and pushed them.
I did modify the changes. My commit explains why.
Thanks!

[kirkshoop]

@furuholm in order for your contributions to make it into the official repo you will need to have a CLA on file. You can do that here: http://cla.msopentech.com/

Thanks!

[furuholm]

@kirkshoop will do!

[kirkshoop]

The official repo has a v2 directory now.

v2 currently has support for

• '.'
  • Allows Intellisense to work.
  • slight perf improvement because the parameters do not have to be stored in a factory object until they are bound to a source by a binary operator
  • has op() to lift external operators into the expression (could be renamed)
• '>>'
  • shows direction of data
  • subscribe and dispose do not flow in that direction
• '|'
  • This is the operator used to combine boost range adapters

The binary operators have the following properties that are distinct from '.'

• Allows operators to be added by reopening the namespace
• Of course, the std namespace does not support identifiers being added - rx probably should do the same
• no Intellisense available
• requires much namespace repetition ala rxcpp::operators::
  • Aliased to rxo:: is a bit better but still a lot of noise
  • I do not recommend polluting the global namespace with identifiers like range, map, flat_map, filter, buffer, window, etc.. so 'using rxcpp::operators' is right out

[kirkshoop]

v2 with support for all three syntax is in master