As the availability of peripheral and driver variants continues to explode on the mbed platform, it becomes more and more difficult to write higher-level functionality that generically takes advantage of what is available. Polymorphism has been implemented in various parts of the code (i.e. network stack) to address this very issue. However, basic peripherals remain lacking. Moving to abstract class definitions (i.e. I2CBase, SPIBase, DigitalOutBase, etc...), or at least virtualization of basic functionality can ease this problem.

Here is one of many example of the problem. I would like to leverage ST's library for the STMPE1600, and I2C-based port expander. The driver constructor expects a I2C class reference to be provided to it. But what if I need to implement I2C as a soft peripheral? Since the mbed I2C class does not support polymorphism through method virtualization, I am forced either modify the ST library or rewrite it. Further, the STMPE1600 class defines its own DigitalIO classes without an inherited/abstracted base. It would be quite useful to be able to able to pass references to STMPE1600 digital I/Os as base mbed DigitalIO classes to other library constructors so that those other libraries would not have to be modified.

So, what are your opinions, pro or con, on virtualizing/abstracting the basic peripheral classes in mbed?

It seems to me to be an issue that doesn't occur often, but I do see your point. Sometimes it is indeed irritating that you cannot easily switch to for example a software implementation of a peripheral. I suppose adding virtual in front of each function definition would be easiest, although not the prettiest? Maybe something that could be discussed on the mbed github. (https://github.com/ARMmbed/mbed-os)

This is a great place to have the conversation ;) If would be great to see some profiling numbers of what the code size and run time performance trade off would be. Something like a chart of compile options versus size and speed starting with I2C and then looking at other APIs this would make sense for.