Re: [boost] Signals & slots library prototype

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-04 09:10:33

From: "Douglas Gregor" <gregod_at_[hidden]>
> On Wednesday 04 July 2001 07:36, you wrote:
> > Could you please describe your modifications in more detail? bind.hpp is
> > still a work in progress. From what I can see, you've added some inline
> > functions that can easy go in a separate header; anything else that I've
> > missed?
>
> That's about it. The changes could go in a separate header but it's a
> dangerous thing to do: if a user includes bind.hpp but not the separate
> header, everything will seem to work but the signals won't know about any
> bound objects; there isn't a very good way to warn the user about this.
Since
> visit_bound_objects is such a small bit of code, I'd prefer if it were
always
> included in the primary binder library header.

Agreed. I see that you've also changed _bind<> a bit to make the data
members public. I'd rather add a 'visit' member, but I'm not sure how VC++
would like that.

> It's the function of visit_bound_objects (and its associated visitor
concept)
> that I would like to discuss. Essentially, signals & slots needs the
ability
> to access each of the bound objects in a slot (slot = any function
object). I
> chose to use a visit_bound_objects free function that takes the function
> object and a visitor, and calls a method in the visitor for each bound
> object.

This is a good approach. I wonder whether it should be generalized, i.e.
rename visit_bound_objects to just 'visit' and define a set of requirements
that an object should conform to to be 'Visitable'.

> There are lots of open issues, the most important of which are:
> - References: can't tell them apart from by-value at the moment. Perhaps
it
> is best to add a "visit_reference" member to the visitor concept.

I'm not sure that I follow. Why would you want to treat references
differently?

> - User-defined pointer types: we need to know where a given object is
hiding
> inside a user-defined pointer type, and how to access it. This is perhaps
a
> separate issue, but is necessary nonetheless.

I don't get that either. :-)

--
Peter Dimov
Multi Media Ltd.