I agree that this discussion would probably be benefit from being included in
the "Add code to super methods” discussion. The one thing that worries me about
the pitch is that it might muck up calling semantics. For example:
class Person {
let firstName: String
let lastName: String
init(firstName: String, lastName: String) {
self.firstName = firstName
self.lastName = lastName
}
func printInformation() {
print("\(firstName) \(lastName)")
}
}
class Employee: Person {
let id: String
init(firstName: String, lastName: String, id: String) {
self.id = id
super.init(firstName: firstName, lastName: lastName)
}
override(before) func printInformation() {
print("Employee \(id)")
}
}
class PartTimeEmployee: Employee {
let workdays: [Day]
init(firstName: String, lastName: String, id: String, workdays: Day) {
self.workdays = workdays
super.init(firstName: firstName, lastName: lastName, id: id)
}
override(before) func printInformation() {
print("Workdays: \(workdays)")
}
}
If someone instantiates a PartTimeEmployee and calls printInformation how do
the calling semantics work? Is PartTimeEmployee called before Employee or is it
the other way around? Also, what happens when after or before isn’t used in a
superclass that is a subclass of something else? When is before or after called
in that situation?
Otherwise, I think the proposals are very similar and would benefit from being
together both from a proposal and implementation stand point.
-Andrew
> On Nov 20, 2016, at 10:01 AM, Jay Abbott via swift-evolution
> <[email protected]> wrote:
>
> Hi Andrew,
>
> There is a similar discussion (in that it solves some aspects of the same
> problem) going on at the moment with the subject "Add code to super methods"
> - check it out. The parts of this problem it doesn't address is that you
> would still have to override multiple init methods to ensure your common
> setup was called regardless of which initialiser is used. However, your idea
> of a post-init call might solve some of of the other issues being discussed
> there and affect that discussion quite a bit. In other words, I think these
> two ideas might benefit from being considered together rather than as
> separate issues.
>
> On Sun, 20 Nov 2016 at 09:58 Tino Heth via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> Initialization is already quite complex in Swift, so I'm very wary of adding
> new features and prefer Derricks idea over a new language feature.
> I hope Swift is still flexible enough for deep changes in this area — I guess
> enforcing that there is always a single designated initializer would not only
> improve on you usecase.
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
