> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution > <[email protected]> a écrit : > > > Regards > (From mobile) > > On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On Jul 9, 2016, at 8:39 AM, Andre <[email protected] >>> <mailto:[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? >
You can’t compare Swift to C++ here. C++ uses « final » method and static dispatch by default, so subclassing does not imply the same fragility than with a fully dynamic language. >> >> -Matthew >> >>> >>> Andre >>> >>>> 2016/07/09 22:11、Shawn Erickson <[email protected] >>>> <mailto:[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] <mailto:[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] <mailto:[email protected]>> のメール： >>>> > >>>> > >>>> > >>>> > Sent from my iPad >>>> > >>>> >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution >>>> >> <[email protected] <mailto:[email protected]>> wrote: >>>> >> >>>> >> >>>> >> Sent from my iPhone >>>> >> >>>> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution >>>> >>> <[email protected] <mailto:[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] <mailto:[email protected]> >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> > >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > [email protected] <mailto:[email protected]> >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
