<div style="white-space:pre-wrap">If you design a module and want to create a public interface for an object which isn't supposed to be subclassed, wouldn't exposing an opaque constructor function and a protocol be a more expressive choice (compared to exposing a sealed class)? </div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 8, 2015 at 04:13 David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">A typical class intermingle several implicit concepts in their design:<div><span style="white-space:pre-wrap"> </span>- The public interface for external modules using the class</div><div><span style="white-space:pre-wrap"> </span>- The internal workings and state of the implementation</div><div><span style="white-space:pre-wrap"> </span>- The interface describing what behavior can and can’t be customized safely by subclasses, and how</div><div><span style="white-space:pre-wrap"> </span>- Possibly an interface for privileged code (“internal” in Swift) to not expose publicly</div><div><br></div><div>public/private/internal, as well as final and the proposed sealed are rough tools to help in making these more explicit.</div><div><br></div><div>What I’m getting at is that in the absence of a completely well-designed class which takes all of these into account, the defaults affect what a typical class looks like.</div><div>- A choice of internal by default means that the class may accidentally not be exposed outside the module for public use, while a public default means that implementation details may be exposed accidentally</div><div>- A sealed class/final method by default means that a class may not be able to be customized in behavior, making the whole framework less useful. Non sealed by default means that classes can be customized, possibly without instruction in ways that are unsafe</div><div><br></div><div>Internal by default seems like a clear cut win - compiler errors or an example program will show classes which were meant to be exposed but were not. If public was default, leaked implementation details may go unnoticed.</div><div><br></div><div>Defaults of public sealed/final classes and final methods on a class by default are a tougher call. Either way you may have design issues go unnoticed until someone needs to subclass to get the behavior they want. So when you reach that point, should the system error on the side of rigid safety or dangerous flexibility?</div><div><br></div><div>The moral of the story is, make your classes sealed and your APIs use prototypes rather than the class directly :-)</div></div><div style="word-wrap:break-word"><div><br></div><div>-DW</div></div><div style="word-wrap:break-word"><div><br></div><div> </div><div><div><blockquote type="cite"><div>On Dec 7, 2015, at 3:20 PM, Joseph Lord via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="auto"><div></div><div>On Dec 7, 2015, at 7:19 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><blockquote type="cite"><div><blockquote type="cite"><span>On Dec 7, 2015, at 11:12 AM, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This was brought up in a different thread about private by default. Creating a new thread for this. Quoting Mathew from the other thread with a short summary about the motivation behind this:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"It is not uncommon to have a need for a reference type without a need for inheritance. Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design."</span><br></blockquote><span></span><br><span>There's a refinement of this idea we've discussed internally in the past. Instead of making classes final by default, we could make it so that public classes are not subclassable from other modules by default. Inheritance is manageable within a module, where all of the involved subclasses are revlocked and potentially have access to each other's implementations anyway, and the benefits of `final` and closed class hierarchy analysis are easy to recover with whole module analysis so don't necessarily need explicit calling out for internal interfaces. The problems with inheritance rear their head more with public interfaces, once code outside your control can subclass your classes.</span><br><span></span><br><span>-Joe</span><br></div></blockquote><br><div><div style="word-wrap:break-word"><div><font><span style="background-color:rgba(255,255,255,0)">I'm a strong supporter of the original proposal of default final classes (and would add to the arguments the performance gains of final even though the compiler can often finalise things anyway). I'm less sure about the within module special case sub classing behaviour (I'm not opposed but I'm not sure it is worth complicating the language for). </span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">Most of the scenarios I can imagine could be implemented with an internal delegate property that provides for the specialisation of behaviour. Are there use cases that couldn't be managed in this way? I suppose it might be a cleaner way to modify varying amounts of the functionality by sub classing but I'm still not convinced for general development that it is worth expanding and complicating the language for different in module behaviour or addition sealed concepts.</span></font></div><div><font><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div><font><span style="background-color:rgba(255,255,255,0)">Joseph</span></font></div><div>@jl_hfl</div></div></div><div><div style="word-wrap:break-word"><div><br></div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43vFcOQoCM-2FU-2BigXPSqPoICJEqmLjcH8XN9oOvmanMg2IaBGNbZC6MQk6e-2Fb1uRxlAB9YNARLB5CPMyluCCMosp3WYGqD2WVeea5I6vUtQpBk-2FS5n9LitwwUNYh8PaNajLEs-2By5uoEcux05BZpD2vKwbgUanim9teNk7QmHWx3nK4cuv-2BU6oheDilymDaOFg5Ih2lt-2FrKd2OOu1HO5OsIWGc-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<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" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1p9Jer2O6jVE9KWvo-2B9iUaEyN8slp4IizyiLwsfp54NVz-2B9b-2FBQIzT368E-2F0eCa1qo-2B6MKXbH9R70-2BF2Ki41B-2FTDEmzGYoiGeNe7RDiucVkUuK9JUIqKdOws5I4QT5wj-2B-2BNhtWzvUacA5pJ-2Fglbf7LKu2bEim7A2jYtgsaVkl6LZmv1Kr2ntKfjKeHhogPUc1y3cwtnJRUWwJrb622hzM0brUN-2BqQtY7xrufMvR6RiE-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div>
_______________________________________________<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>
</blockquote></div>