on Tue Nov 29 2016, Michael Ilseman <milseman-AT-apple.com> wrote: >> On Nov 28, 2016, at 7:22 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Thu Nov 24 2016, Michael Ilseman <[email protected]> wrote: >> > >>>> On Nov 17, 2016, at 2:54 AM, Tino Heth via swift-evolution >>> <[email protected]> wrote: >>>> >>>> An equivalent of "NS_REQUIRES_SUPER" (hopefully with a better name ;-) has >>>> been requested several >>> times, but never got the momentum it deserves. >>>> Considering the current confusion (especially in UIKit), it would be >>>> really nice to have some help from the compiler, and I wonder how >>>> composition and protocols would be helpful here at all. >>>> >>> >>> As an intermediary measure, this seems like an interesting QoI >>> improvement for the compiler: warn when super.foo() is not called in >>> the overridden method. >> >> Please no. Methods that need to be called when they are overridden are >> almost always a result of poor design. >> >> “I don't always do Object Oriented Programming, but when I do, I use >> the Template Method Pattern" >> >> understating-the-case-ly yrs, > > I agree, that’s why I’m suggesting it be a ObjC-side attribute for use > by e.g. UIKit.
OK, that's fine; it sounded like you were proposing a blanket rule. Apparently UIKit equally needs an attribute that says “*don't* call super,” and that would be a good idea for Swift too. It can also be expressed as “this method is private but overridable,” but I know that idea gives some people the hives :-). > Regardless of how both of us may feel about UIKit’s design, it is the > largest platform on which apps are made and there’s a chance for the > compiler to enhance the developer experience. I do agree that we > should be careful about condoning the practice for new/Swift-only > frameworks. Heck, I'm not even going that far. I'm just saying I don't want to “un-condone” designs that don't require super-calling. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
