On 22.07.2016 11:15, Dave Abrahams via swift-evolution wrote:
....skipped...
IMO, the safety of API contracts is secondary. This is about safety of
implementation - my code is possibly not "resilient" enough (to to
speak) to handle overriding arbitrary public members.
I wrote that subclassability is not an important element of safety
**independent of overriding**. If you don't allow any overriding,
your code is always “resilient” enough to handle subclassing.
I believe in this case the #2 approach, as formulated in proposal, just
can't work - base class of public class can have(and can add) `open`
methods/props, so for the author of such public class it is hard to know
what other methods (other than explicitly marked by him/her as `open`)
would be overridden.
So, seems like for #2 approach the proposal should be changed to not
implicitly open inherited `open` methords/props. Author of public class in
this case must explicitly mark as `open` each method/prop one wants to
export opened.
Then, in this case, we have a problem with *inherited* methods/props that
author *want* to open. In this case to remove boilerplate like 'public open
func f() { super.f()}', I don't see another way than adding new concept of
re-introducing of inherited method without its body :
public class B : A {
public open *reintroduce* var property // without type/details
public open *reintroduce* func foo() // without body
public open override func bar()
{
//some code
super.bar()
//some code
}
public open func newFunc() {...}
public func sealedFunc() {...}
}
(`reintroduce` as fast example of possible keyword for implementation of
such feature)
Am I missing something?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
