> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > >>> >>>> 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 agree that this is implementable. I would be very reluctant to do it, though; it amounts to writing off all of the performance advantages of the proposal. (And possibly the semantic advantages as well, like being less restrictive about required initializers.) John. > > >>> >>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
