> Am 07.07.2016 um 02:27 schrieb Jonathan Hull via swift-evolution
> <[email protected]>:
>
> 1) This method MUST be overridden
> 2) This method should NOT be overridden
> 3) This method MUST be called
> 3) This method should NOT be called except by subclasses
> 4) This method should NOT be called except by a method override calling
> super
> 5) This method MUST call super
> 6) Overrides of this method should NOT call super
>
> If we are attempting to bring thoughtfulness to the design of classes, I
> would like to see things be extendable by default, but with annotations that
> thoughtful framework designers can use to designate how a particular method
> should be used. In most cases, it should not explicitly forbid the end user
> from subclassing, but require them to acknowledge that what they are doing is
> not intended by the framework. (e.g. "unsafe override func"…). That would
> feel 1000x more swifty to me. Opt-out safety.
totally agree:
I'm not sure what 3) should mean, but imho several points on this list are much
more useful than the ability to seal a class.
Imho it is not necessary to forbid overloading at all, it's better to make sure
everyone trying to do so is aware of the dangers (imho exclamation marks would
be a "swifty" choice: "override! func(…)).
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
