"required" also doesn't mean that a subclass has to implement the required
initializer since it can be inherited.
Your example is an abstract function which should have it's own keyword (if
we ever get abstract functions).
···
On Wed, Dec 16, 2015 at 7:37 PM, Vester Gottfried < vester.gottfried@gmail.com> wrote:
I think reusing required would send the wrong message. Required would mean
for me something like NSOperation subclasses maybe require to have a main()
function, but that doesn't mean you have to call super. On the contrary,
the documentation of NSOperation main() explicitly states not to call
super.On Wed, Dec 16, 2015 at 7:08 PM, Marc Knaup <marc@knaup.koeln> wrote:
What about re-using the "required" keyword in the superclass which
already means something similar for initializers?
Subclass implementations are required to call super's implementation.
If a subclass doesn't implemented the required method it could mean that
it inherits the behavior from the superclass - just like initializers can
be inherited too.On Wed, Dec 16, 2015 at 7:02 PM, Jordan Rose <jordan_rose@apple.com> >> wrote:
+1 from me. FWIW, the Objective-C one is syntactic.
Information from Radar: the request for this is rdar://problem/17408107
(plus a few duplicates). One of the dups suggests a variation where a
subclass method can be declared as "refine" instead of "override" so that
you can document that your *own* method is expected to call super. In
this model, "@requires_super" could become something like "imposed". I
personally think this doesn't add enough, especially since we wouldn't be
publishing refine-vs-override in a library's public interface.Jordan
On Dec 16, 2015, at 9:49 , Marc Knaup via swift-evolution < >>> swift-evolution@swift.org> wrote:
Sounds reasonable since even the best flow analysis cannot ensure that
all codepaths call the super implementation.Some more edge cases:
- Calling super asynchronously by using it in a closure
- Referring to the super implementation by assign it to a variable
and call it later (is that really possible? never did that)On Wed, Dec 16, 2015 at 6:25 PM, Vester Gottfried < >>> vester.gottfried@gmail.com> wrote:
I would suggest that @requires_super only checks if a call to super is
present at all. More detailed behaviour should be part of the functions
documentation, because I think all possibilities cannot be checked easily
by the compiler. For example a call to super my be required to happen early
or late inside the function. But when too early or too late is can probably
not been forseen by the compiler.On Wed, Dec 16, 2015 at 5:46 PM, Marc Knaup <marc@knaup.koeln> wrote:
+1 always had such issues with UIViewController's lifecycle methods.
But edge cases need to be considered like "throws" for example.
Do I need to call super before I throw something?On Wed, Dec 16, 2015 at 5:41 PM, Matthew Johnson via swift-evolution < >>>>> swift-evolution@swift.org> wrote:
+1 to this. Anything that helps ensure inheritance is thought
through carefully and used correctly is a win.On Dec 16, 2015, at 10:32 AM, Vester Gottfried via swift-evolution < >>>>>> swift-evolution@swift.org> wrote:
Some class based libraries/frameworks expect the consumer to subclass
certain classes and override specific method and require that the super
implementation of an overridden method is being called.Not calling the super implementation is a common source of bugs that
may be prevented if the compiler checks if super is called, like it does in
some cases of init().Example:
class Box {
@requires_super
func addStuff() { ... }
}Overriding class Box's addStuff without calling super.addStuff()
should result in an errorclass Chest : Box {
override addStuff() {
// ERROR: addStuff() requires call to super.addStuff()
...
}
}Objective-C developers know this as NS_REQUIRES_SUPER and I think its
worth thinking about adapting it.I hope my proposal was clear and thanks for reading,
Gottfried
_______________________________________________
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
