RE: [boost] Re: Review: lambda library

From: Gary Powell (powellg_at_[hidden])
Date: 2002-03-19 11:20:59

Well in 20/20 hindsight some of these design choices become more obvious. LL
has (first as ET and Bind) has gone through at least 3 major revisions. Each
time we have been able to abstract out things we had thought needed to be
embedded in the library. Hence the effort to "boostify" I'm hoping will get
the next round of changes out. (Or not if we managed to do it.)

  Once you start down a path of design one tends to keep going until
reaching its logical end, its like having a new hammer, the world starts to
look like a bunch of nails. When in fact there are screws and bolts etc.
everywhere too.

  -Gary-

-----Original Message-----
From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]On
Behalf Of Peter Dimov
Sent: Tuesday, March 19, 2002 3:34 AM
To: Boost List
Subject: Re: [boost] Re: Review: lambda library

From: "Gary Powell" <powellg_at_[hidden]>
> True enough, but we got here because after using LL for a bit, we started
> wanting more. You know how this goes, first you say, ah hah! We've got
> ll::for_each, then we realize what we want is a nested "count_if" and
pretty
> soon all of the STL algorithms are cloned into lambda. (not the algorithm,
> just a wrapper to forward it to std::STL).
>
>   Then we added exceptions, and we realized we needed to be able to
> "construct" objects to throw them. So that got added, then.... and well
you
> can see the result. (or rather the "trim" version.)

I can contribute another point of view on library design in order to balance
things. :-)

When using bind, I sometimes encounter problems that the library doesn't
address directly. Instead of immediately adding the feature, I look at the
problem with the eyes of an "ordinary" user that doesn't have access to the
source, and ask myself: "how can I solve this problem without making changes
to the library?"

For example, how can I make the first argument of a bind() expression be
evaluated? I write a helper apply<> function object. It needs no support
from bind in order to work.

Or, how can I construct an object? I'd provide a construct<T> function
object; again, no changes to bind are necessary, it just works.

How can I throw an exception from within bind? I can write a throw_exception
function object.

Of course, all these helper function objects are not lambda expressions, so
I won't be able to say construct<T>() + _1, but bind(construct<T>()) + _1 is
not _that_ much.

There are things that belong in the library. _1 + _2 is much better than
bind(std::plus<R>(), _1, _2). But we have to draw the line somewhere; you
can't provide direct support in LL for everything; it's better to focus on a
simple, well understood, logical subset of primitives that allow people to
do everything without bothering you with feature requests.

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost