Boost :

fcacciola_at_[hidden]

--
   :-)
"Joel de Guzman" <djowel_at_[hidden]> escribió en el mensaje
news:009501c2a3de$319bb370$a7564eca_at_kim...
> ----- Original Message -----
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> > > What's wrong with borrowing a well formed concept from
> > > other languages? That's definitely better that concocting a
> > > half-cooked version of what's already a mature concept in
> > > other languages.
> > >
> > There's nothing wrong with that, but it is important to
> > notice that on a different language there are different
> > tools, so what works best on one does not necesarily
> > work best on another.
> > For instance,  I don't know if you can have a
> > stack-based fixed capacity and variable size container
> > on Haskell. But you can have it on C++, so following
> > this model in C++ make sense just as it makes sense
> > to follow the union model.
> >
> > I'm not arguing against the union model; I'm just arguing
> > that the variable-size-container also works; and IMO better,
> > but even if it were not better, it is clearly not worse; and
> > IMO, containers are more familiar to C++ programmers
> > than _discriminated_ unions.
> > But the difference is negligible, and I didn't want
> > to imply otherwise.
> > On both models you have a box which can have a 'T',
> > but in the variable-size container, if you don't have a T
> > you have nothing; while on the union model you have an X.
> > T-or-nothing maps better IMHO to the optional T concept
> > than T-or-else.
> > But I know both models completely work.
>
> Now we are in agreement ;-) Indeed you can model the optional
> that way and it ~might~ be more intuitive to the C++ programmer.
> May I request however that the alternative model, which IMO is
> no less equivalent, be at least noted in the documentation? For
> some, including me, that model is more intuitive and even elegant.
>
Actually, because of the very important precedence in Hashkell,
and because variable-size containers are typically associated with
dynamic memory allocation, unlike variant, the new doc starts with
the union model, and develops the semantics out of it.
Then it shows that the nil_t is not really needed explicitely, and can
be hidden, which amounts to going from a container of T-or-nil_t
to a container of T-or-nothing; introducing the variable-size-container
but as an API on top of the union.
I decided to follow this road because I know that at some point the
implementation will do just that: it will put a layer on top of a
variant_t<T,nil_t>; so the documentation will make more sense
this way.
Fernando Cacciola