Re: [boost] Re: Re: Re: Re: Formal review: Optional library

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-12-14 21:03:12

----- 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.

> > All these are based on a wrong premise.
> 
> Are you sure you meant to say _all_ these?
> How about this part:
> 
> > > If you trust my experience with this tool, I assure you that if you are
> > > accesing the value of a conceptually non-existent object,
> > >  you've made a mistake on the code because the execution path
> > > should never had reached that point.

Pardon my all too sweeping statement. You are right in this regard.

Cheers,
Joel de Guzman
joel_at_[hidden]
http://www.boost-consulting.com