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-13 15:39:15

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.  I'd question the value of replacing legacy inheritance based type systems with TypeErasure based type system for its own sake.  It needs to enable something worthwhile or I'd rather the developer effort go elsewhere.  I'm not disagreeing with Dave, I'm just saying its usefulness needs to be evaluated on a case by case basis.

With inheritance based type systems you get a tower-of-babel problem where everyone wants to talk about the same thing, but everyone has created a different language to talk about it with different base classes and interfaces.  That leads to a type incompatibility problem between different modules in any reasonably large real world application.  What the library allows you to do is define an interface that unifies the divergent inheritance hierarchies that have no base class in common, but do have concepts in common.  We could do that with static polymorphism in the past, but there is still scope in the needs of C++ programmers to use dynamic polymorphism.  For example, a container of objects of different size/type (perhaps by reference) that all have a concept in common.

A real example from an application I have worked on is that two object types inherit (eventually) from the same base type and each has an interface for a concept they have in common.  Getting some attribute of the object.  However, that interface isn't a method of the (common) base class and is declared differently for each of the two types.  Epic fail.  With TypeErasure you can declare an interface that accepts any object of either type and knows how to map the concept they have in common to the disparate interfaces of the various types without needing to fix the broken inheritance hierarchy, which is often not feasible due to the mass of legacy code that may depend upon it.  While such a situation might seem contrived, I would say it is pretty typical of legacy C++.  Even within the same dynamic polymorphic type system you can easily end up with senseless type incompatibilities.  Once again, we could also solve it with static polymorphism.  All the library does is layer type erasure on top of static polymorphism to make non-intrusive, type-safe dynamic polymorphism.

Regards,
Luke