Thanks for the thoughtful responses, its appreciated.
> 2016/07/09 23:30、Matthew Johnson <[email protected]> のメール：
>
>> 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.
I see, makes sense and I get a better idea where this is going… its how I feel
as well...
> 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.
What are your thoughts on an ability for a way to force unseal a class that
does need to be fixed, even if its temporary?
Something like:
class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits a
scary compiler warning
}
Does that even seem feasible/possible, much less reasonable…?
Though it would have to be a perhaps separate discussion, this comes to my mind
as becoming necessary down the road, but maybe I’m wrong...
> 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).
This is also, to me, a thing I am concerned about… its kind of an unknown I
suppose...
> 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.
Yes…. Well, anything that gets third parties to open up their closed frameworks
is a big win-win IMO… some of them are not very good (to put it mildly) and
could use more scrutiny.
> I have seen some comments about nontrivial complexity in Apple’s frameworks
> caused by apps subclassing where they should not have (i.e. classes that
> would be sealed if it were possible in Objective-C). This is extremely
> unfortunate and it impacts everyone on Apple’s platforms.
>
> I wish I had links handy for you, but I don’t recall exactly where or when
> this was mentioned and don’t have time to dig them up right now.
I see, thats reasonable… if those links are available somewhere I would
definitely like to see them, it would be a good education for me…
---
A little more for me to think about, but maybe I can cast a vote in a little
bit…
Again, thanks for the thoughtful response!
Andre
>>
>> 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]
https://lists.swift.org/mailman/listinfo/swift-evolution
