Corrado Zoccolo wrote:
Hi boosters, I think that Adobe poly approach on "operator . overloading" could be extracted as orthogonal to the polymorphic object container concept, and easily generalized to serve all kinds of wrappers.
My proposal (see code in the vault: *http://tinyurl.com/5xo9or*) is to have a class template (interface<T,W,B>) that describes the interface of type T, forwarding any operation to the implementation type, got directly from the wrapper (W). B is used when vertical inheritance is needed, either to benefit of EBO or to insert a base class on top of the hierarchy (see type_erasure_wrapper). There is actually a fourth boolean parameter, that will be explained later.
Such a complicated and specific mechanism. I think a lot of people come up with lots of approaches at overloading the dot operator which really do not truly overload its meaning. What that operator takes is an an object, a name, and arguments. Therefore, in my opinion, overloading the dot operator should mean calling a function with a compile-time string and those arguments. Then, with proper compile-time introspection support (an mpl map of compile-time strings to functor types), one can for example choose to call a member function with that name on some type, or do something else.