In Java, you make the function part of an interface to achieve that:
interface Foo {
void foo();
}
class A implements Foo { ... }
class B extends A { ... }
If someone renames Foo then A and B fails to compile. If you don't want to use an interface, you do it like this:
class A {
abstract void foo();
}
class B {
void foo() { ... }
}
Yes, it's not exactly equivalent but, this is a rather contrived case that never happens in Java because
a) almost everyone uses @Override because IDEs add it automatically
b) Java programmers don't refactor by using VI and editing a base class's method names. An IDE like IntelliJ IDE does all the work automatically.
c) if you really want to ensure that a class implements a certain interface, you use a Java interface to enforce it.
This swift feature is interesting, but it's not really anything to sell the language.
Yeah it's interesting seeing the contrast in interpretations of "will change the way I program". In one world you have go which aims to truly solve one of tomorrow's biggest programming problems (concurrency), while btw never experiencing this override "bug" since it doesn't allow subclasses and circumvents entire classes of issues altogether, and on the other hand you have Swift which seems to address some rather minor qualms (IMO) with a drastic syntax change.
Swift provides high-level concurrency as well; it just does so via Grand Central Dispatch rather than any built-in language primitives. (While there are no intrinsic language features comparable to Go's channels, I was told that part of the reason for the new trailing closure syntax was so that GCD invocations would look more 'natural'.)
I don't think Swift is trying to sell itself based on the 'override' modifier, overflow-checked arithmetic, Unicode variable names, or any of the other minor features which people keep on talking about. It has a far more capable type system than Objective-C ever had. Its pattern matching is far more than "C's switch statement, but without automatic fall-through". Except for backwards-compatibility, it de-emphasizes or eschews the many at-runtime dynamic features that Objective-C had (e.g. creating and modifying classes and methods dynamically). It has tuples. It's a huge departure from Objective-C, not just incremental improvements packaged into a new language (not that it invented these new features, of course), so it's doing more than just addressing 'minor qualms'.
interface Foo { void foo(); }
class A implements Foo { ... } class B extends A { ... }
If someone renames Foo then A and B fails to compile. If you don't want to use an interface, you do it like this:
class A { abstract void foo(); }
class B { void foo() { ... } }
Yes, it's not exactly equivalent but, this is a rather contrived case that never happens in Java because
a) almost everyone uses @Override because IDEs add it automatically b) Java programmers don't refactor by using VI and editing a base class's method names. An IDE like IntelliJ IDE does all the work automatically. c) if you really want to ensure that a class implements a certain interface, you use a Java interface to enforce it.
This swift feature is interesting, but it's not really anything to sell the language.