RE: [boost] Proposal: statefull objects

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-07-20 10:22:50

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, July 20, 2001 9:24 AM
Subject: Re: [boost] Proposal: statefull objects

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > In order to introduce this proposal let's consider the following
> situations:
> >
> > CASE A:
> > =======
> >
> > struct image
> > {
> >   ...
> >   int get_pixel( int x, int y) const ;
> >   ...
> > } ;
> >
> > How should we deal with the case of x,y being outside the image?
>
> A function should not try to do too many things.
>
> bool is_inside(int x, int y) const;
> color_type get_pixel(int x, int y) const;
>
My point is not about returning pixels from an image. It is just an example.
I'm sure you can come out with an example that suits you. (A function that
might not return a value in a situation were that is not an exception).
Or simply take the case of set/map insert().

> [Other cases that demonstrate the point better snipped.]
>
> > I'd like to know your opinions.
>
> This is a discriminated union, like 'any'. The only difference is that
'any'
> accepts any type + void, while your proposed class accepts only T or void.
>
True, but that difference makes it useful for completely different purposes.

I wrote this some time ago to ease a particular problem (the loop case), but
after that, I found that it turned out to be very useful in every day
programming. Now I use it widely, just as I use shared_ptr, or noncopyable,
etc...
I decided to submit it because I've been using it for months and it helped
the clarity of the code a lot.

You may think that I am solving my problems the wrong way, just like you did
with respect to the image example, but then I invate you (and everyone else)
to consider how and when would you use this in your every day working.
I bet that within a few months you'll get conviced that this is just as
useful as, say, shared_ptr.

> People that program in discriminated-union-capable languages would like
your
> proposal. :-) Do you think that optional<T> would be a better name?

Good name, seems better to me...
I will *see* it in my code to see if it *looks* right.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com