On Fri, 26 Mar 2021 at 23:48, Tony V E <tvaneerd_at_[hidden]> wrote:
>
>
>
> On Fri, Mar 26, 2021 at 3:50 PM Ville Voutilainen via SG7 <sg7_at_[hidden]> wrote:
>>
>> On Fri, 26 Mar 2021 at 21:32, Barry Revzin via SG7 <sg7_at_[hidden]> wrote:
>> >
>> >
>> >
>> > On Fri, Mar 26, 2021 at 2:00 PM David Rector via SG7 <sg7_at_[hidden]> wrote:
>> >>
>> >> Attached is a new paper addressing how the P2237/P2230 facilities might be expanded to be able handle the `Sum<T,U>` example discussed awhile back, and more generally subsume the capabilities of the "string-injection" approach, while avoiding its drawbacks.
>> >
>> >
>> > Hi David,
>> >
>> > I didn't understand the Sum<T, U> example before and I still don't. There's not really a description of it in the paper, just a lot of code. What problem is it demonstrating?
>>
>> I don't understand the lack of understanding. It's basically
>>
>> For two types T and U
>> - generate a product-type wrapper X that
>> * for every member function $foo appearing in both T and U, has a
>> member function X::$foo that returns the sum of the results of T::$foo
>> and U::$foo
>> * otherwise, for any member function $bar appearing in just one of
>> T and U, has a member function X::$bar that returns the result of
>> either T::$bar
>> or U::$bar depending on which one is present
>>
>> It's just an example of a wrapper like that, a particular kind of
>> mediator, where the API is the union of the APIs of the mediated
>> types.
>
>
>
> This is an explanation I can understand!

I don't actually find it much more than a rephrasing of what was
written by David in his earlier attempt
to depict this, which was this:

// Methods: the union of the methods of T and U.
  // Wherever they "share" a method, such that names and
  // signatures of method reflections m_t and m_u are the same
  // (not necc. via inheritance) that method is implemented
  // to return t.[:m:](…) + u.[:m:](…). Otherwise, it returns
  // t.[:m:](…) or u.[:m:](…) individually.