Re: [boost] Boost Overload Documentation

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-10-12 12:42:10

Hi Michael,

On 10/13/07, Michael Fawcett <michael.fawcett_at_[hidden]> wrote:
> On 10/12/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> > On 10/12/07, Marco Costalba <mcostalba_at_[hidden]> wrote:
> > >
> > > So I would say a _possible_ policy is to not allow to register say
> > >
> > > set(f6);
> > >
> > > if is already registered a function with a "compatible" signature.
> > >
> >
> > This is wrong.
> >
> > I would have said:
> >
> > " a _possible_ policy is that a call like
> >
> > f.set(f6);
> >
> > overwrites any exsisting function with the same signature *or with a
> > compatible signature*"
>
> Why is that better than your original wording?  Your latter
> description breaks from precedence set by std::set and map.
>

I don't think we have to follow the precendent by std::set and
std::map because of two very important reasons:

1.) The Boost.Overload implementaion does not follow the Contianer
concept -- not by a long shot. If at best, it's closer to an
std::pair<> than an std::map<> or std::set<>. This is because
Boost.Overload is not a container -- it never was, and it never will
be.

2.) The concepts and the use cases for Boost.Overload are not meant
for run-time consumption: therefore throwing exceptions and runtime
dispatch is out of the question. This means doing a set(&foo1) is
better than saying insert(&foo1) because 'set' conveys better the
concept which Boost.Overload is making as compared to 'insert'. See #1
as to why this is the case.

Again, if you're looking for a container for runtime function objects,
see Boost.Signals and the (other) library I'm working on, the Runtime
Dynamic Dispatch Library. At best, you might want to consider an
std::map<> of Boost.Function objects instead.

I hope this makes things clearer.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]