> On Jul 6, 2016, at 1:41 PM, Goffredo Marocchi via swift-evolution > <swift-evolution@swift.org> wrote: > Sent from my iPhone > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> <swift-evolution@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. > > I see closed by default as part of the movement some people seem to be > embracing of opt-out model in which freedom and versatility is forcefully > restrained, making the language more complex and exotic/breaking conventions > for the sake of protecting people from themselves, instead of opt-in models > which require programmers to be diligent and know when to constrain > themselves while enjoying more flexible defaults. > I am not asking for JavaScript, but I do not want this language to go the > complete polar opposite, more dogmatic than C++ or Java.
This proposal is specifically targeting library interfaces. It's not a slippery slope towards locking things down at a sub-library level because (1) we've already considered and rejected the analogous sub-library-level proposal (as "final by default") and (2) almost all of the justifications are tied to the specific problems that arise with library interfaces. In general, Swift already treats library interfaces as a special point at which a lot of considerations change. The most prominent example of that is access control, but there are a lot of other examples that will become more apparent as we complete the resilience model, solidify the ABI, and start really supporting binary distribution of libraries. The basic idea is that library designers face a set of language problems that other programmers don't, and the language ought to understand that and provide a different set of features and defaults. This is a language design that's made possible by Swift's relatively strong commitment to defining and enforcing library boundaries, as opposed to the languages you list. To me, this is a great way to only get dogmatism when it's actually useful and necessary. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
