Re: [boost] any

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-04 07:21:58

> >> I agree that ref<> itself is not a cloning pointer, but from my
> >> perspective the role it can play overlaps strongly. So a clearer name
> >> would be a start.
> >
> >I'm open to suggestions. :)
>
> Err... <thinks>... <sidetracks> How about listing what you think are its
> defining features, and from that drawing a name that seems to capture
> this or at least part of it?

To paraphrase Scott Meyers, ref<T> is an object that is designed to act,
look and feel like the value it holds.

Unfortunately, due to technical constraints, I had to replace r.f() with
r->f() and added *r as a companion.

> >Perhaps I misinterpreted your original intent, however.
>
> A little, but the idea of a customised double and single dispatch engine
> was what I had in mind;

In this case, having a boost-accepted double dispatch engine would be a
start.

> making any behave exactly like a statically-
> typed value was not -- that's what statically type values are for ;->

Not if you get handed an 'any' from somewhere else - e.g. interpreters. As
you said, static typing is not sufficient.

> However, I did not see this as part of the core any offering, ie it is
> something that a user can layer on top according to preference. I also
> would not support a combinatorial explosion of operations, eg int and
> double, char and string and char *, and so on.

I think that you should explain this extended_any concept in more detail.
How does the user layer an operator+ on top of any? How are the possible
conversions controlled by the user? How is any(int) + any(std::string)
handled, i.e. is this an int or a string?

--
Peter Dimov
Multi Media Ltd.