[boost] Re: associative_list

From: Emily Winch (emily_at_[hidden])
Date: 2002-02-15 05:05:19

Vesa Karvonen said:

> --- In boost_at_y..., "Emily Winch"  wrote:
> > There's an associative_list,[...]
> > for anyone who wants to have a look.[...]
>
> I had a very quick peek and haven't actually tried the code, but I
> think I spotted a bug:
>
>     self_type& operator=(const self_type& other){
>       self_type temp = other;
>       temp.swap(other);
> //    ^^^^      ^^^^^
>       return *this;
>     }

<going red>

oops. OK, I shall fix my lousy tests :) Evil pixies put that there.

> Some random thoughts:
>
> At any rate, this is interesting - mainly because this class is not
> exactly either a run-time nor a compile-time component.

Yeah, I'm really fascinated by the Misty Land Between Run-Time and
CompileTime. 

> The name "associative_list" is perhaps a bit too generic for this
> class. Mainly because it doesn't say that it uses types as keys and
> objects as values.

I think you're right. There's probably a use for an associative_list which
associates types with types. This seems to be a common pattern: a family of
components that differ only in how much is known at compile time.

std::vector<boost::any> -> std::vector<Andrei's variant> -> boost::tuple

std::multimap -> associative_list (of types and values -> 
                                associative_list (of types and types).

std::vector -> mpl::type_list

I'm at a loss for a decent naming convention though :(

> My intuition tells me that something is missing. Perhaps it is the
> higher order algorithms or perhaps something else.
>
> Have you considered mutating algorithms such as push_front
> (assoc_list,value)?

I did. My logic for not having them is simply that I haven't yet found a use
for them. If anyone else does, in they go.

> Does the associative_list allow multiple elements with the same key?

Yep. That ought to go in the documentation. My next plan was one that
doesn't, but yet again I'm stuck for a name. 

Thanks,

Emily.