[boost] Re: Re: Making any visitable

From: Itay (itay_maman_at_[hidden])
Date: 2002-04-28 01:29:05

"Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
news:aa798d$d3b$1_at_main.gmane.org...
> "Itay" <itay_maman_at_[hidden]> wrote in message
> news:aa746t$3gm$1_at_main.gmane.org...
> > That's true. Any's visitor does not meet the textbook's requirements for
a
> > visitor class. Nonetheless it does have a 'visitorish' quality. Hence,
> I'll
> > try to outline the requirements for a boost::any semi-visitor:
> [snip]
>
> Note that (a) you define the requirements yourself (b) you call visitor
> something that's not a visitor.
>
I tried to summarize the requirements that were (implicitly) mentioned
throughout this discussion, so, it is a personal view, but it is based on
needs/requirements of others. As for the naming issue, you got me convinced:
We should use a more appropriate name (The best name I can come up with is
'Any extractor', but I don't like it too much ....).

> [snip]
> > Parameterizing boost::any on the type of the visitor seems like a
> reasonable
> > compromise. (imposed by (1))
>
> Given the self-imposed requirement, well, there's not much implementation
> flexibility out there for grabs :o). I believe that's not a reasonable
> compromise.
>
> [snip]
> > By all means, boost::any is not a usual class, so its visitor is a bit
> > eccentric, as well. Nonetheless, even when visiting anys, the concrete
> > functionality is defined by a (statically typed) policy. I believe that,
> for
> > most practical purposes, this is an acceptable degree of freedom.
>
> The any class cloaks a polymorphic type. The cloaked polymorphic type
should
> have a virtual function (actually, two) that enables visitation. That's as
> simple as it goes, and it makes transition from a closed class to an open
> class. I don't see how any being a unusual class implies that it must have
a
> severely restricted visitor. I think the idiom you describe is unusable.
You
> do need more visitors for a given type, otherwise you don't care much
about
> visitation.
>
>

A visitor is allowed to manipulate a host object through the host's public
interface. (Actually, this is what my static visitor implementation does
when used with a default VisitMethod policy). However, when visiting an any,
you can't do anything interesting with the public interface, which is due to
the fact that any has no knowledge of the type (or value) of its internally
held data. That's why visiting an any is more complicated than just adding
an accept() member function.

An any object can hold, hmm, anything. Hence, it is quite important to have
a mechanism which will generate compile-time errors whenever the applied
functionality is used with an any held value, of an inappropriate type. If
this applied functionality is wrapped up in a non-stateless policy you can
actually combine multiple policies into one and set an internal data member
to select the current one. (This is how my 'any extractor' works).

When I compare this approach with Dimov's approach (presented in this
thread), I must admit that Dimov's visitor is a real visitor (unlike mine).
But if we accept the assumption that the number of applied policies is
statically known, then an 'any extractor' will be able to deliver the same
functionality, with the additional advantage of alerting at compile time.

Itay