>>
>>> 2016/07/09 23:30、Matthew Johnson <[email protected]
>>> <mailto:[email protected]>> のメール：
>>>
>>> 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...
>
> I'm not opposed to something like this in principle, but I'm not sure how it
> would work in practice. There was some discussion of something along these
> lines on the list at one point (I think Joe Groff had some ideas). However,
> I don't think this is possible if the optimizer takes advantage of the sealed
> status when the library is compiled. I'll leave it to the compiler experts
> to comment further on feasibility.
My technical analysis: It’s certainly implementable to have the optimizer not
take advantage of the sealed status, and to allow some sort of
“unsafe-break-the-seal” syntax. We’d have to be sure that anything that “can’t
possibly happen without external subclassing” still at least generates a
deterministic trap rather than memory corruption, but that’s probably doable.
(I’ll leave it at that, without trying to argue a particular side.)
>>
>>> 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…
>
> IIRC like Jordan Rose may have made some comments along these lines either on
> list or on Twitter if you want to search, but that is a fuzzy memory and
> could easily be wrong. :)
I don’t have anything handy (partially because some of it isn’t public
knowledge), but it’s a well-known phenomenon within Apple that new OSs break
third-party apps in strange ways because they are relying on being able to
swizzle a non-public selector, or even on its existence. I’ll admit I don’t
hear as much about intrusive subclassing, but that doesn’t mean Apple hasn’t
made changes that assume no one subclasses a particular class.
[For anyone who doesn’t know the term “method swizzling”: Objective-C allows
you to replace a class’s implementation of a method at run-time, regardless of
where the class or the replacement is defined.]
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
