3 ms·

Because extensibility should be a design decision.

• chii 3y ago
  extensibility not thought of during design is a flaw. which can be patched over if the actual internals are reachable.
  • everforward 3y ago
    Sure, but extensibility often comes with complexity. If I'm making something non-extensible it's to keep things simple or to prevent a bunch of bugs around people trying to extend something with complicated state. They always have the nuclear option of forking and making those fields no longer internal. They'll have to take on the maintenance overhead that I shirked, but that should be fine if they need it that badly.
    • kriz9 3y ago
      I agree. Most of my frustration comes from unescessary abstractions and not code that I can't extend.
    • chii 3y ago
      > They always have the nuclear option of forking and making those fields no longer internal. while that is always possible, it is not always reasonable. If you take firefox as the example, the removal of the XUL extension api is one such. And while there's many a forks to keep the old XUL api, none of them really caught on, and so support for them such as maintaining security patches etc fails.
• mst 3y ago
  That feels like an argument for 'final' more than 'private.' Personally, at least for library code, I tend to assume -somebody- will extend any given class of mine at -some- point and would prefer they had a reasonable time doing so, but I use 'prefer' advisedly since there are absolutely situations where doing so would almost certainly be a footgun and in that case I'd rather dissuade the user before sinking time into the idea.