Documentation revisions: additional reasons for using this library ie. why it, rust traits and go interfaces should be used 85++% of the time
1) Ease of use and teaching from not overdesigning
in many OOP implementations types start virtualized at least with a virtual desctructor as one does not know who will be inheriting from the class in the future. It is taught by default you should be putting virtual ~ClassName() on all your classes for this very reason. This is contrary to the C++ philosophy that you only pay for such if you are actually using it. This popularized code pattern has turned into an antipattern. It is tragic when a type is only accessible from within a module as the developer is in full control. It could still be over used on module public api, ie. between module, if destruction was never needed ie. object life time was not a factor of the algorithm's that operated on said type.
2) Ease of use and teaching from not overdesigning
C++ multiple inheritence. "there are no polymorphic types but rather polymorphic use"
similar to the over design for the the unknown future in virtual destructors one must virtually inherit from other classes in case the class gets inherited from latter. The virtual keyword is again overused and the decision is made at class definition time instead of at class usage time.
3) Modules which are great can encourage over design. Specifically that in 1) and 2). A lot of this, but not all, becomes unnecessary when using traits/dyno where the library writer only requires that which is actually being used.
...
This educates users on when they should be used and makes the case for its adoption into boost and future C++ standards.
Documentation revisions: additional reasons for using this library ie. why it, rust traits and go interfaces should be used 85++% of the time
1) Ease of use and teaching from not overdesigning in many OOP implementations types start virtualized at least with a virtual desctructor as one does not know who will be inheriting from the class in the future. It is taught by default you should be putting virtual ~ClassName() on all your classes for this very reason. This is contrary to the C++ philosophy that you only pay for such if you are actually using it. This popularized code pattern has turned into an antipattern. It is tragic when a type is only accessible from within a module as the developer is in full control. It could still be over used on module public api, ie. between module, if destruction was never needed ie. object life time was not a factor of the algorithm's that operated on said type.
2) Ease of use and teaching from not overdesigning C++ multiple inheritence. "there are no polymorphic types but rather polymorphic use" similar to the over design for the the unknown future in virtual destructors one must virtually inherit from other classes in case the class gets inherited from latter. The virtual keyword is again overused and the decision is made at class definition time instead of at class usage time.
3) Modules which are great can encourage over design. Specifically that in 1) and 2). A lot of this, but not all, becomes unnecessary when using traits/dyno where the library writer only requires that which is actually being used.
...
This educates users on when they should be used and makes the case for its adoption into boost and future C++ standards.