Boost logo

Boost :

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-15 14:34:31

on Fri Jun 15 2012, "Hite, Christopher" <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at