[boost] Re: Re: dynamic_any

From: Alexander Nasonov (alnsn-mycop_at_[hidden])
Date: 2003-05-08 03:23:09

Lin Xu wrote:

> I know. I know the pattern, it is not what I was talking about. Perhaps I
> should have been more specific, I was referring to the
> .. std::ostream & (std::ostream &, const anyT &)
> That you have to parse. I believe boost.Function does that already, the
> parsing of the template argument, I mean;

Do you mean by "parsing" splitting off the arguments using 
Boost.function_traits, for example?

> and the docs say that the
> "compatibility" syntax is used for older compilers.

I decided not to support compilers without partial specialization. 
Therefore, there is no "compatibility" syntax for dynamic_any::function.

> But that's not really a big deal...because I understand now!
> 
>>I don't understand what do you mean by "distinguish".
> Nevermind, I didn't understand.
> 
>>move()(a, 10, 10);
> This explained everything. I understand now.
> 
> You implemented a dynamic any visitor whereas I implemented a mixin class.
> But we both implemented the same functionality. Except, that you can visit
> using an arbitary class. Very cool: but ...
> to clarify; does the move class need to be defined in the any type?
> ie..
> typedef dynamic_any<move> some_any;
> some_any a;
> 
> Or can I just do
> dynamic_any<> a;

Yes, you have to include move into the sequence of supported operations:
typedef dynamic_any< mpl::vector<move> > some_any;
It makes a programmer intention clear. There was a conversion between 
some_any and any<> but I decided to drop it off. After all, user can define 
convert operation if she needs it.

> Another question: I see that you call operator() on the visting object.

Are you referring to a call with comments in the code snipset below?

struct visit
  : boost::dynamic_any::function<visit, void (visitor &, const anyT &)>
{
    template<class T>
    void call(visitor & v, const T & value) const
    {
        v(value); // are you referring to this call?
    }
};

> I dont' see that explicitly defined in the move class by the user.

I can't find a common point between this sentence and previous one.

> I would
> assume it woudl be defined by the dynamic_any, except you did define it in
> the io_any test. Thanks for letting me pick your brains :)
> 
>>One problem that I see right now is a single interface bottleneck.
> Well, there isn't. I avoidedd that issue, but today I implemented multiple
> ones using a mpl::list. It wasn't difficult; I just hadn't implemented it
> at the time I wrote the email.

Even if you do so, the problem is still remains because when you write *a 
you get the access to a single interface. What does matter that this 
interface is a mix of different interfaces which can have undesireable 
intersections. Two of them may have, let's say, common print function. One 
will hide another (or will cause ambiguity if you use multiply inheritance 
in the implementation). Which one will be hidden depends on the order of 
interfaces listed in mpl::list.

> However I think mine is not superior to yours, except maybe in syntax. (I
> still don't like the seperate syntax move()(....)). That's just coming
> from where I began my any, which was from the idea of a mixin..not a
> dynamic visitor in which case it makes sense. However, if all one wanted
> was a sort of forwarding function that would call the same function in the
> any, then the any->function_call() seems more natural.

I agree that a->move(10, 10) is clearer then move()(a, 10, 10). One big plus 
of it is ability to overload move member-function: a->move(Point(10, 10)). 
You can't do that with move operation:
  move()(a, 10, 10);
  move()(a, Point(10, 10)); // error
You have to implement two operations move_to_xy and move_to_point:
  move_to_xy()(a, 10, 10);
  move_to_point()(a, Point(10, 10)); // ok

But, looking at the single interface bottleneck and less clear 
implementation of supported operations, I prefer to use my-own move()(a, 
10, 10).

-- 
Alexander Nasonov
Remove minus and all between minus and at from my e-mail for timely response