[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Mike Sanderson]

On Fri, Jul 15, 2016 at 2:26 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jul 14, 2016, at 10:58 PM, Charles Srstka <cocoadev at charlessoft.com>
> wrote:
>
> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> - Second is that clients of some other public API vended by a non-Apple
> framework (e.g. a SwiftPM package) may end up in a situation where the
> framework author didn’t consider subclass-ability, but the client desires
> it.  In this situation, the core team feels that a bigger problem happened:
> the vendor of the framework did not completely consider the use cases of
> the framework.  This might have happened due to the framework not using
> sufficient black box unit testing, a failure of the imagination of the
> designer in terms of use cases, or because they have a bug in their
> framework that needs unanticipated subclass-ability in order to “get a job
> done”.
>
>
> Or because the framework was developed in the real world, rather than
> Elysium, and real-world framework developers just about *never* anticipate
> every single way someone might use their framework (Indeed, if developers
> were capable of such a thing, there would be no need for third-party
> software in the first place).
>
>
> I’m not sure what you’re trying to say.  I agree that it is clearly the
> case that a framework author cannot anticipate every single use case of
> their framework.
>
> However, it is just as clearly the case that “unanticipated
> subclassability” isn’t a general solution to that problem.
>

In the case of open-source frameworks, there is a better solution, simply
to fork. Fork, make the alteration, point the dependency manager to the
fork, and if you think it's of general applicability, submit a pull request.

And this does happen all the time. Not just unanticipated use cases, but
general bugs, bugs from a particular way it's used, some tweaks to adjust
some variable, need something fixed to be altered, designers ask for
something to be moved 10 pixels to the left, etc., including things
subclassing wouldn't even be able to fix. I've had to do this more than a
few times, and it actually never occurred to me to make a subclass for this
reason. A proposal that closed off the only way or the best way to handle
these cases would be unwelcome, but this doesn't do that.

It's another topic, but I think having a fork of open-source dependencies
anyway is prudent, as our friends in javascript learned with their recent
Node Package Manager left-pad fiasco. The left-pad fiasco also indicated
that relying on framework authors to be communicative or to be maintaining
their work or even to be not deliberately spiteful, is not good practice.
Fortunately in the case of open-source we do have that control; in the case
of Apple frameworks the assurances offered as part of sending it for
revision are welcome; and if this puts onus on publishers of third-party
close-source frameworks, ok.

-MikeSand



>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/0c272ea7/attachment.html>