Re: [boost] An alternative approach to TypeErasure

Subject: Re: [boost] An alternative approach to TypeErasure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-06-24 18:23:08

AMDG

On 06/24/2012 02:53 PM, Pyry Jahkola wrote:
> On 2012-06-24 18:34:13 +0000, Steven Watanabe said:
> 
>> On 06/24/2012 08:13 AM, Dave Abrahams wrote:
>>>
>>> Very interesting.  Does either approach support operator overloading?
>>
>> Yes.  I put quite a bit of effort into making
>> sure that operator overloads would work
>> correctly.
> 
> I started the work on operator overloading, as you might guess when
> seeing the file
> 
>    include/poly/operators.hpp (names in this file will definitely change)
> 
> I didn't get so far that poly::interface would actually recognize these
> callables and create the corresponding operators for itself, but that
> sure is possible.
> 

If you have to create special cases for these
in the core library, you're doing it wrong.

> More importantly, I'm still kind of missing the point of why the feature
> of operator overloading is really needed. In essence: How should binary
> operators behave? Steven's TypeErasure defines binary operators such
> that only when the wrapped types of a and b are the same, can you sum
> them up: "a + b".
> 
> But where would you use this kind of an "any", where only some of the
> instances can be added up, and others cause undefined behavior? Wouldn't
> you actually do the addition on the side where you know the types, and
> not on the type-erased side?
> 

Binary operators like this require you to have
a coherent set of objects.  You can't just
take two random objects from two different
sources and combine them.

There are also a few special cases where binary
operators can have a reasonable default behavior
when the types don't match.  For example,
equality_comparable<> and less_than_comparable<>
can test the stored /types/ first before testing
the value.

> Do we really have a real world use case that would prompt us to
> implement features like operator overloading?
> 

any_iterator.

Also, you're confusing two separate issues.
Operator overloading is a separate issue
from binary methods.  Some operators, like
ostreamable<> or incrementable<>, would
normally only take one any argument.

> * * *
> 
> Before releasing more worms from the can of type-erased operators, I
> must confess that I know still too little about the possible uses for
> type erasure / expression problem / what you name it. What I propose is
> we should look into how e.g. Haskell and Clojure programmers use their
> type classes and protocols.
> 
> For one thing, I could only think of few examples where the interface
> would have mutating functions. (Anybody care to throw in more examples?)
> 
> More typical use cases (that I could think of) are functions which read
> the wrapped type (as const reference), and then either (1) return a
> value, or (2) cause a side effect:
> 
>    std::string(to_html_, self const &);        // (1) "pure" function
>    void(print_, self const &, std::ostream &); // (2) side effect
> 
> Maybe if the whole interface is about wrapping some sort of computation
> or side effect, it might make sense to have some non-const functions too:
> 
>    using progress = interface<
>        std::size_t(total_progress_, self const &),
>        std::size_t(current_progress_, self const &),
>        void(run_for_, self &, std::chrono::microseconds)>;
> 
> Or maybe it's modeling a kind of a container and you can insert items
> into it:
> 
>    using container = interface<
>        void(insert_, self &, std::size_t, content),
>        void(remove_, self &, std::size_t),
>        content &(at_, self &, std::size_t),
>        content const &(at_, self const &)>;
> 

In Christ,
Steven Watanabe