Regards (From mobile) > On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On Jul 9, 2016, at 8:39 AM, Andre <[email protected]> wrote: >> >> Personally, Im not against sealed by default, but I think there are cases >> where closed source libraries have certain cases where workarounds are >> necessary, and just sealing by default will prevent those cases. >> >> One could say, "well just use an open source one, or change vendors" but its >> not that easy in The Real World™ where we get certain SDKs shoved down our >> throats by the suits… and while that may be a separate issue to the one at >> hand, its still a problem that won’t resolve itself by simply locking down >> things… >> >> In my own case, Ive fought with NSBrowser / NSTreeController in the past and >> the only way to resolve things was to subclass (and no, waiting 1 or 2 years >> for a fix is not acceptable if you already have a product in the wild). >> >> So I am reticent to support this proposal without an escape hatch for those >> cases… > > Are you concerned about closed-source vendor frameworks beyond Apple’s? Some > things to consider: > > 1. This proposal should not impact any existing libraries - nobody should be > shipping closed-source binary libraries written in Swift yet. > > 2. Apple’s frameworks will probably remain in Objective-C for some time to > come. If / when they are replaced with Swift frameworks the default will > have little (if any) impact on the public API contract. It is reasonable to > expect that Apple will review the public contracts carefully and add any > annotations necessary to achieve the desired semantics. > > 3. In the future, if you depend on any 3rd party closed-source libraries > written in Swift you will be able to ship an update to your app that contains > an updated / fixed version of the library independent of the user upgrading > their OS. > > This leaves the scenario of a case where you depend on a 3rd party, > closed-source library written in Swift and where you cannot get (or use) a > fix from the vendor for some reason. This is a legitimate concern, but IMO > it is not large enough to outweigh all of the advantages of making sealed the > default. > > There is no doubt that adopting sealed by default will place some pressure on > the Swift ecosystem. As others have noted, this pressure already exists in > the form of value types, protocol-oriented designs, etc - the current > proposal is a relatively modest increase in that pressure. I believe the > pressure will have a very positive impact over time (the eventual outcome > remains to be seen of course). > > Swift library vendors will need to choose between opening their source, > providing responsive support and bug fixes, explicitly providing the escape > hatch you mention (by designing with open types) or getting a bad reputation > among users.
There are IMO no advantages to sealing by default. If there were, I cannot imagine how they can have so consistently eluded the designers and maintainers of so many great OOD languages in the last 30 years. Does it mean it is just a matter of time for the core team to take it the c++ standardization committee to make sure C++ gets enhanced the same way? > > -Matthew > >> >> Andre >> >>> 2016/07/09 22:11、Shawn Erickson <[email protected]> のメール： >>> >>> 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. >>> >>> 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 >>>> <[email protected]> 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 >>>> > <[email protected]> のメール： >>>> > >>>> > >>>> > >>>> > Sent from my iPad >>>> > >>>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution >>>> >> <[email protected]> wrote: >>>> >> >>>> >> >>>> >> Sent from my iPhone >>>> >> >>>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution >>>> >>> <[email protected]> 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 >>>> >> [email protected] >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > [email protected] >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
