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.
···
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 <swift-evolution@swift.org> wrote:
on Thu Nov 24 2016, Michael Ilseman <swift-evolution@swift.org> wrote:On Nov 17, 2016, at 2:54 AM, Tino Heth via swift-evolution >>> <swift-evolution@swift.org> wrote:
--
-Dave