|
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" <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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk