5 ms·
There are some edge cases because of which this had to be done, I think. For example calling static methods via the instance variables, the actual method called
by swaranga 4y ago
There are some edge cases because of which this had to be done, I think. For example calling static methods via the instance variables, the actual method called would be the static type of the variable at compile time and not the actual type at runtime:
public static void main(String[] args) {
Parent instance = new Child();
if (instance instanceof Child p) {
instance.print(); // prints Parent
p.print(); // prints Child
}
}
static class Parent {
static void print() {
System.out.println("Parent");
}
}
static class Child extends Parent {
static void print() {
System.out.println("Child");
}
}
Hence, with flow typing, existing code could break in subtle ways.
- hilbertseries 4y agoIf you’re writing code calling static methods on instances of classes, you deserve to have that code broken.
- recursive 4y agoI've always wondered why that's even allowed.
- _Nat_ 4y agoIt's actually the default in C#. This is, in C#, all methods are called according to an object's apparent-type, not its actual-type, by default. To get the Java-behavior, a C#-method would need to be declared `virtual` (or `abstract`), and then more-derived methods would need to choose to `override` them (rather than hide them, often via `new`). Part of the advantage might be performance. This is, methods that go with the apparent-type don't need to do a virtual-lookup-table resolution, which can save some work in method-calls. Another advantage is that it can help provide more flexibility in class-hierarchies, since more-derived classes can "hide" less-derived classes' methods without overriding them. It's probably not something that folks really need to do too often, but it's nice to have an easy solution when such a case occurs.
- recursive 4y agoYou're talking about virtual vs non-virtual. static is a whole separate thing. static calls are always resolved at build time. You don't even need an instance at all. And probably shouldn't use one.
- _Nat_ 4y agoRight -- it's an issue of virtual vs. non-virtual, not static vs. non-static. For example, [this comment](https://news.ycombinator.com/item?id=31379783 https://news.ycombinator.com/item?id=31379783 ) provided code showing the issue in this branch of the thread using `static` in Java. Here's the same thing in C# without using `static` (except for `Program.Main()`): public class Program { public static void Main() { A a = new B(); if (a is B b) { a.Print(); // Prints "A". b.Print(); // Prints "B". } } } public class A { public void Print() { System.Console.WriteLine("A"); } } public class B:A { public new void Print() { System.Console.WriteLine("B"); } } `static` can work too because it implies non-virtual, but it's not necessary. Generally speaking, virtual-methods resolve with dependence on the object they're called on since they consult a [virtual-method table](https://en.wikipedia.org/wiki/Virtual_method_table https://en.wikipedia.org/wiki/Virtual_method_table ). Non-virtual methods can resolve without considering the object they're called on (whether static or not) because they call the method that belongs to the apparent-type.
- recursive 4y ago> it's an issue of virtual vs. non-virtual, not static vs. non-static. That's what you started talking about, but that's not what I'm talking about. > "calling static methods on instances of classes" That's from an ancestor, somewhere upthread. Here it is as a c# expression. "abc".Format("size: {0}", 7) Sensibly, c# doesn't allow this, but some languages do. I don't recall which, but I've definitely seen this. Maybe I'm not understanding a word or something, but the description of the problem is definitely about "static".
- pjmlp 4y agoInfluence from OOP languages that preceded Java.
- quantified 4y agoProbably didn’t get written that way but arrived there when that class was refactored somehow.
- SemanticStrengh 4y agoHow does Kotlin solve those use cases? > instance.print(); // prints Parent why? the parent print should be shadowed/overidden by the child bruh
- spullara 4y agostatics don't override
- SemanticStrengh 4y agooops my bad
- yarg 4y agoDoes java provide warnings against calling static methods on Objects?
- smarks 4y agoYes, if javac is given the `-Xlint:static` option.
- smarks 4y agoSeveral folks have pointed out the poor style in calling static methods using an instance. I think you have a good point, but not a good example. Perhaps a better example is with overload resolution. Consider this Kotlin code: fun foo(i: Int) = ... fun foo(n: Number) = ... fun main() { val n: Number = 12; foo(n); // calls foo(Number) if (n is Int) { foo(n); // calls foo(Int) } } It's as if smart casting causes the static type of `n` to change in different parts of the main function. As such it also seems to affect overload resolution. Maybe this is exactly what you want. On the other hand it seems like it could lead to some very subtle errors. I'm not a Kotlin programmer, so Kotlin experts please feel free to correct me on details.