[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Sat Jul 9 09:20:48 CDT 2016

When I expose an API it is to hide details behind it for the benefit of
myself - as the library developer - and to benefit the library user by
hiding complexity and giving them a well testable and tested contract. The
"myself" benefit also benefits consumers of the library since it gives me
the ability to more freely rework things under the hood overtime since I
was able to bound what users of my libraries should have been able to do
(in code dependency terms). I also can limit how much defensive programming
I may need to do.

I don't really see that as an attitude against users of a library.

Also note again I am going to present you with an API that in the swift
realm will have very few subclass able points, it will be protocol based
likely and heavier in structs, etc

Anyway it would be good to separate the votes against closed by default
from those against the ability to close a public class.

-Shawn

On Sat, Jul 9, 2016 at 9:37 AM Goffredo Marocchi <panajev at gmail.com> wrote:

>
>
> Sent from my iPhone
>
> On 9 Jul 2016, at 14:11, Shawn Erickson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> What I don't get in the arguments against this capability is the fact that
> many constructs in Swift can't be subclassed. Are we going to prevent
> library developers from presenting those in the public API? Your ability to
> subclass things when not supported by the library developer is already
> going to be greatly reduced. Additionally you are going to miss potentially
> helpful optimization in side the model if the library developer can't
> prevent extras subclassing.
>
>
> This is one case where the automagical optimisation comes at a cost that
> you should be knowingly paying for. An explicit keyword that seals the
> class across module boundaries seems like would do the job just fine.
>
> Also, sorry for the off topic here, libraries are meant to be used by
> others and developed for others and we should have helping others in mind
> developing them. We also should be humble enough to admit that we will not
> be able to explicitly allow/predict all use cases and empowering our users
> to experiment, report issues, and add features through pull requests. The
> attitude behind some of the sealed by default reasons I have seen here does
> not seem it is what we should have in open source software. We do not want
> a situation where the library author puts the library and not the users on
> the pedestal.
>
> It seems perfectly reasonable to allow a lot of freedoms for a library
> developer when designing their code on their side of the library API and
> not force them to expose unwanted API just because of internal design
> desires.
>
> (I have myself have already struggled with having to leak what I consider
> internal details outside of modules we have developed internally, likely
> need to get around to outlining the additional issues I see)
>
> In the end if the library isn't good and you don't like the API find one
> that works the way you need (or make one). I expect a fairly rich
> environment of libraries that will sort itself out over time.
>
> -Shawn
> On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hi,
>>
>> > However, you *do not* want any new subclasses added as you know that is
>> not likely to end well.
>> Im curious, what kind of real-world scenario would "not end well" cover?
>>
>> I’m genuinely curious, since Im still on the fence about this, but am
>> willing to be convinced… if sealed by default brings more positives than
>> negatives…
>>
>> Thanks in advance.
>>
>> Andre
>>
>>
>> > 2016/07/09 21:36、Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> のメール：
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>>
>> >>> Even in Java, it is a bad idea to leave classes subclassable; but
>> having to remember to add final is a chore.
>> >>
>> >> I still think it is worth doing that chore. The fact of the matter is
>> that Java did not and is not enforcing that default and how many widely
>> used production languages you know that do enforce this by default instead
>> of asking library authors to do this bit of work?
>> >
>> > People keep talking about just adding final.  This *is not* an
>> alternative.  We are not talking about preventing subclasses by default
>> (i.e. final by default).
>> >
>> > We are talking about preventing subclasses *in other modules* by
>> default (i.e. sealed by default).  The alternative would be to introduce a
>> sealed keyword (or similar).
>> >
>> > There are times when you *need* to use subclasses inside your module.
>> Some or all of them may not even be directly visible externally (class
>> clusters).  However, you *do not* want any new subclasses added as you know
>> that is not likely to end well.  This is why having sealed, not just final,
>> is important.
>> >
>> > By choosing sealed as a default rather than final, we are keeping the
>> "subclassable by default" status *within* modules.  This facilitates
>> experimentation and eliminates the need for application level code to
>> opt-in to subclassing while still making external API contracts explicit
>> and therefore hopefully more robust.  It is the default most in-line with
>> the values and goals of Swift.
>> >
>> > 'final' and 'sealed' are two very different things.  Let's please keep
>> this focused on what is actually being proposed.
>> >
>> >>
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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/20160709/0c28f5a0/attachment.html>