[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Paul Cantrell]

> On Jul 6, 2016, at 3:41 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
> 
>> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> In the era of increased open sourcing, easy forking, and more community-driven development, this concern is less severe than it used to be. I rarely use any closed-sourced libraries for iOS development. If I need to tweak some library and non-subclassibility is getting in the way, then I can fork it — and perhaps even contribute my changes back to improve the upstream project. In an open source world, “closed by default” makes a lot more sense.
> 
> Maintaining a fork, realistically often without hope of upstream merging, your changes is feels like a very business unfriendly idea and less scalable than it sounds in many environments.

It certainly has its problems, but in practice it’s no worse than brittle workarounds such as unintended subclassing.

In the case of forking, upgrading a library comes with the cost of merging changes. In the case of brittle subclassing, upgrading a library comes with the cost of your patches suddenly breaking. In either case, you have a body of code which is tightly coupled to an external library in ways that the library's author isn’t monitoring for breakage.

In my experience, forking is usually the less costly route because it gives more control. Modern version control makes maintaining a fork over time much easier than it used to be — and the ever-improving social dynamics of pull requests make forks less likely to live on forever.

Cheers,

Paul