RE: [boost] [Review] bind

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-17 18:17:06

----- Original Message -----
From: Douglas Gregor <gregod_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 17, 2001 6:47 PM
Subject: Re: [boost] [Review] bind

> On Friday 17 August 2001 05:19, you wrote:
> > Aside from the conflicts with functional -which I'm not sure how could
be
> > solved-, I vote for inclusion.
> >
> > I second the argument of replacing the _N notation for boost::argN.
>
> I'll vote against boost::argN, because I think that the _N notation is
> wonderfully terse and that it stands out well with syntax highlighting
> available.
> In any case, it isn't a latent error: if one uses 1 instead of _1
> or vice-versa, it will result in a compiler error.
>
The crucial potential conflict I see is not that you can forget to type the
underscore, but that other identifiers or nasty macros might collide.
In these cases syntax highlighting won't help, and compiler errors might be
just too confusing.

> > What I am not sure to accept is the visitor mechanism, it looks rather
> > halfway to a more general callback coupling mechanism.
> > Though I admit that I couldn't quite imagine the usage of 'accept'
beyond
> > the example given, I have the intuition that it provides a mecanishm
that
> > is not as carefully thought as the rest of the library. It could end up
> > being a rather partial solution to a more general problem which might
need
> > to be addressed more deeply: the coupling of function objects and
> > callbacks.
>
> I can speak up for any shortcomings in the visitor mechanism. I've been
> working on a signals & slots library. One of the requirements is that
> connections between signals and slots only live as long as any of the
objects
> that are bound by either. For instance:
>
> Button* closeAll = new Button(...);
> Window* w1 = new Window(...);
> closeAll->onClick.connect(bind(&Window::close, w1));
> Window* w2 = new Window(...);
> closeAll->onClick.connect(bind(&Window::close, w2));
>
> If w1 or w2 is destroyed, the connection between closeAll->onClick and
that
> window object must be severed to avoid a segmentation fault. The signals &
> slots library shouldn't define a bind member (creating function objects is
> orthogonal to the callback mechanisms), so we need an external way to
visit
> each of the bound subobjects. The visitor mechanism was the only one
> proposed, and we have yet to see a good, clean solution. Problems include:
>   - want to minimize dependency between signals library and binding
library
>   - all function objects must be able to accomodate a visitor
>   - shouldn't place this requirement on all function objects (otherwise it
> would annoy users).
>
> All solutions so far that decouple bind libraries from the signals library
> have been deemed too brittle :(.
>
I see.
It appears that a coupling mechanism is so important that even a hack is
better than nothing.
In that case, then, let's leave it the way it is.

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