On Thu, Nov 27, 2025 at 6:28 PM Thiago Macieira wrote:
> >
> > class Pink : public IMicroscope, public IUtility, public IDrift,
> > public IIllumination, public IStage, public IEscape, public
> > IObjective, public IDiagnostics, public IIris, public IPower, public
> > IAsyncControl, public ICommsHandler {
> > . . .
> > };
>
> I am calling this a poor API design. It might have been the height of
> propriety back in the 1990s when OOP and polymorphism was all the rage, but it
> isn't today. Therefore, I don't think a solution is applicable to new code.


Are you saying that the Pink microscope should have been done
something like the following?

    template<typename... Ts>
    class Microscope { . . . };

    typedef Microscope< Stage, Objective, Diagnostics > PinkMicroscope;

Or maybe sub-objects instead of base classes:

    class Pink {
      Stage stage;
      Illumination illum;
    public:
      IStage &GetStage() noexcept { return stage; }
      IIllumination &GetIllumination() noexcept { return illum; }
    };

Or maybe more like COM-ish style:

    template<class Interface>
    Interface *query(Pink&);

    if ( auto *s = query<IStage>(pink) ) { ... }

The original way the SDK was written with multiple inheritance from
abstract base classes and polymorphism (i.e. virtual functions) hasn't
gone out of fashion yet.


> However, we are left with legacy. If you can show in your paper:
> a) this problem exists often enough;
> b) there is a Standard Library solution that would greatly alleviate the
> problem;
> c) this type of code is still in enough active development they would adopt
> new Standard Library solution (at the earliest in 2028).
>
> then it could be adopted into the Standard.
>
> Again, looking forward to the paper.


I'm close to putting pen to paper. Just need a more solid idea on how
I'm marketing this, i.e. whether it's

(1) Compensating for bad code
or:
(2) Compensating for old code
or:
(3) Adding a useful new feature

Maybe it's doing all three.