[swift-evolution] Final by default for classes and methods

[ilya]

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)?

On Tue, Dec 8, 2015 at 04:13 David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> A typical class intermingle several implicit concepts in their design:
> - The public interface for external modules using the class
> - The internal workings and state of the implementation
> - The interface describing what behavior can and can’t be customized
> safely by subclasses, and how
> - Possibly an interface for privileged code (“internal” in Swift) to not
> expose publicly
>
> public/private/internal, as well as final and the proposed sealed are
> rough tools to help in making these more explicit.
>
> 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.
> - 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
> - 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
>
> 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.
>
> 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?
>
> The moral of the story is, make your classes sealed and your APIs use
> prototypes rather than the class directly :-)
>
> -DW
>
>
>
> On Dec 7, 2015, at 3:20 PM, Joseph Lord via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 7, 2015, at 7:19 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Dec 7, 2015, at 11:12 AM, Javier Soto via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 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:
>
>
> "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."
>
>
> 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.
>
> -Joe
>
>
> 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).
>
> 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.
>
> Joseph
> @jl_hfl
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20151208/565c59c5/attachment.html>