> > This thread arose in response to what is undeniably a bad API > authoring practice (first allowing full ctor override and later > breaking BC without fanfare) Why are we letting the authors of > Richard's library off the hook and putting it on ourselves to develop > hacks? They obviously screwed up. What next? Do we let API consumers > override a `final` that they don't like? Just use the right pattern in > the first place. IMO. >
I disagree. It can be perfectly ok to allow the lib to be extended and the constructor extended/replaced with a compatible one. The problem is, that currently there is a scenario(lib didn't had a constructor but now it does) which is a PITA. Either the lib author needs to add an empty constructor into every class just to make sure that it will be there to provide a painless upgrade when the need arises for a constructor otherwise the lib consumer has to write boilerplate to make sure that the parent constructor will be only called whet ot is there. Your example also shows an overengineered solution for a simple problem. I think that this is QoL improvement which can be implemented to have a reasonable gain without any cons.
