UartController un-sealed?

Would it be possible to have the UartController un-sealed in the future? It would be handy to be able to pass a custom implementation into the Modbus interfaces (as an example) to handle LED blinking or other base tasks in UartController overrides.

Now im just learning here so i dont mean to add noise in lieu of the correct answer, but might it be possible by implementing your own IUartControllerProvider and instantiating a custom UartController via the FromProvider method?

public class CustomUartConroller : IUartControllerProvider

and then

var myUartController = UartController.FromProvider(new CustomUartConroller());

In fact it seems as there is already an implementation in the framework:


This just came to mind as i’m trying to figure out how to give gpio on external devices like the mcp23xx a native feel.

I think there’s an argument to be made to be able to extend each of these controllers Uart, Gpio, Spi, iic, ect.
Not sure of the benefits or drawbacks to just unsealing these classes, but i too would like to see some support/examples of how to extend these correctly.

1 Like

To me, “separation of concerns” says that annunciator (LED) functions should be separate from UART functions ( but setting that aside for a moment, I actually am not sure why these classes are ‘sealed’. What’s the benefit?

Defining and accepting interfaces on the modbus class would be an option (and probably a better design), but every byte counts on these small devices and I think that would probably end up generating more IL (compiled bytes) than just unsealing the classes.

There is a good discussion here: The main reasons seem to be performance (though no data is presented) and “not designed to be inherited from”.

@Dat_Tran or @Gus_Issa - can you help us understand the original reasoning here?

i recall reading that SO thread more than once. and while i believe it’s good to have the option to seal a class, it always seems there was a great reason to seal it until someone proves that there wasn’t…

and i never understood what the performance benefit beyond compile time could be.

I asked that multiple times.
They refer to encapsulation, inheritance and polymorphism as the three pillars of object oriented programming. In TinyCLR we are denied of inheritance.
I ended up using code composition, i like inheritance better

Inheritance VS Composition

Inheritance Composition
In inheritance, there is an image of the base class in the derived class object, so the image of the base class is created when the derived class object is created. Composition allows late creation of the backend class object until and unless they are not really required.
Base class remains a part of the derived class object throughout the life of the derived class. In composition, life of the backend class is independent and we can change back end object dynamically.
Inheritance is static binding (compile time binding) Composition is dynamic binding (run time binding)
Inheritance can denote an “is - a” relationship between classes. Composition can be denoted as being an “as a part” or “has a” relationship between classes.
Inheritance comes with polymorphism. NA
In inheritance, there is a single invocation of an inherited base class so there is no extra cost for invocation. The explicit method invocation (forwarding or delegation) has a performance cost (note that performance depends on many factors).
A change in the base class interface cannot ripple down the inheritance hierarchy to a derived class. It is easy to change the interface of a back-end class and front-end class
In inheritance, it is not required to implement all base class methods within the derived class. In composition, all methods provided by composed classes must be implemented in the front end class.
The derived class and base class interfaces are tightly coupled. The front-end and back-end interfaces are loosely coupled.

It is easier to add new derived classes in inheritance than to add new front-end class in composition.