2016/07/09 23:30、Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> のメール：
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