So either open by default and sealed optionally or sealed by default and no escape hatch?
On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > > 2016/07/09 23:30、Matthew Johnson <matt...@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 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution