Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-06-15 12:31:00

> Dave Abrahams wrote:
>>> that the scope of TypeErasure was to replace inheritance–based 
>>> polymorphism whenever possible.
>
>> That's definitely one useful way to apply it.
>
>> I would say the scope of the library is to provide (type safe) runtime 
>> polymorphism whenever inheritance-based polymorphism is not possible.

>Seriously?  So, you would dispense with boost/std::function because an inheritance-based approach is possible?

I wasn't trying to define the entire scope of the library, just to state what I think is definitely in its scope that is in sharp contrast to the "replace whenever possible" suggested scope.  Clearly there is scope for the library includes both cases where inheritance is a viable option and cases where it is not.  I was trying to draw attention away from use cases that overlap with existing use of inheritance to highlight what the library makes possible that inheritance doesn't.  I would say the motivation for this library is particularly to enable the things that inheritance doesn't cover very well.  If people understand this library as only a more verbose and confusing way to do exactly the same thing they having been doing with inheritance then most of the value of the library will be overlooked.  Type erasure and inheritance really isn't an either/or proposition.  They play well together.  One thing I like about this library is it shifts the focus of design away from "objects" and to "interfaces", where I think it belongs.  Providing an interface that uses TypeErasure and additionally providing an abstract base class that the user of the interface can inherit from if they choose for convenience in satisfying the concepts required by the interface would be perfectly valid interface design decision, and probably a good idea for interfaces that require complex concepts to lower the bar for using the interface enough to get the majority of C++ programmers over it.

Regards,
Luke