> On Jul 9, 2016, at 7:59 AM, Andre via swift-evolution
> <[email protected]> wrote:
>
> 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]> 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…?
I am also of the opinion that we need an "escape hatch" and I think Joe G
notion of patch-ability should be part of this review.
Alternatively I think at least having a way to add:
patch extension mySealedClass {
defer(methodOnClass(label01:,etc:) ){
/// code I want to run right after method.
}
}
I think something that is able to run right after a method would help at least
some until the library author is able to fix the class. There is probably a
small cost on attaching defer code to method but you won't need to subclass to
fix certain bugs.
> 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]> のメール：
>>>>
>>>> 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
