on Fri Jun 15 2012, "Hite, Christopher" <Christopher.Hite-AT-partner.commerzbank.com> wrote:
Dave Abrahams wrote:
Sure. For new code, it's reasonable to consider a value-based paradigm in lieu of legacy inheritance paradigms.
Dave I think generally if you personally were going to start a new project you'd try hard to avoid fat interfaces anyway. Can you picture yourself asking a user to implement an interface with a dozen methods on a object?
I can't, but I don't see the relevance.
I completely agree with using functors for simple interfaces.
By "functors" do you mean runtime-polymorphic function objects?
There need to be good utilities to type-delete them.
Consider this big monster object with this interface. It's not movable/copyable (maybe it has its own threads). I think you'd find something like this acceptable.
struct monster : noncopyable{ typedef signal<void ()>::slot_type slot;
connection subscribeA(slot); connection subscribeB(slot); connection subscribeC(slot); ... };
If it's not movable/copyable it has already failed the test. The idea is to construct a world of values, and this is not one.
Now let's say for some reason we need run time polymorphism two impls of monster. I would propose making subscribe* virtual. Would you really do something different?
Didn't we say this was about new code? If you've got legacy stuff like this you do what you have to do.
Would you do something like this?
typedef function< connection (slot)> S; typedef tuple<S,S,S> deleted_monster;
template<T> deleted_monster make_ deleted_monster (T&); // uses names ABC
I think the use case for value based interface for a fat interface doesn't come up much.
I don't understand what point you're trying to make. -- Dave Abrahams BoostPro Computing http://www.boostpro.com