<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 2:26 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Jul 14, 2016, at 10:58 PM, Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><blockquote type="cite">On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">- 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”.</span></div></blockquote></div><br><div>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).</div></div></div></blockquote><br></div></span><div>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. </div><div><br></div><div>However, it is just as clearly the case that “unanticipated subclassability” isn’t a general solution to that problem.</div></div></blockquote><div><br></div><div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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. <span style="font-size:12.8px">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.</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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 t<span style="font-size:12.8px">o be maintaining their work or </span><span style="font-size:12.8px">even</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">to</span><span style="font-size:12.8px"> be</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">not </span><span style="font-size:12.8px">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. </span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">-MikeSand</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>-Chris</div><br></font></span></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>