0

It is certainly not for good OOP design - as the need for common behavior of all instances of a derived class is quite valid conceptually. Moreover, it would make for so much cleaner code if one could just say Data.parse(file), have the common parse() code in the base class and let overriding do its magic than having to implement mostly similar code in all data subtypes and be careful to call DataSybtype.parse(file) - ugly ugly ugly

So there must be a reason - like Performance ?

As a bonus - are there OOP languages that do allow this ?

Java-specific arguments are welcome as that's what I am used to - but I believe the answer is language agnostic.

EDIT : one could ideally :

<T> void method(Iface<? extends T> ifaceImpl){
    T.staticMeth(); // here the right override would be called
}

This will also fail due to erasure (in java at least) - if erasure is at work one needs (would need) to actually pass the class :

<T, K extends T> void method(Iface<K> ifaceImpl, Class<K> cls){
    cls.staticMeth(); // compile error
}

Does it make sense ? Are there languages doing this already ? Is there a workaround apart from reflection ?

Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
  • How would you determine the subclass type with a static method? You don't call a static method on a specific object of a certain type. You call it on a class. – MAV Nov 29 '13 at 19:07
  • @MAV: I might pass a class object - such as `Class extends Data> cls` and then do `cls.parse()` - you determine the subclass when you have an instance examining the object at hand (fast via the vtable) - in the static method case one would have to examine the class object (via a static vtable ?) – Mr_and_Mrs_D Nov 29 '13 at 19:13
  • @MAV: Or even better : ` void method(Iface extends T> iface){ T.staticMeth(); }` - which all this is syntactic sugar around the class vtable invocation - the class is known at runtime. In java in particular all this will doubly fail as generics are not reified – Mr_and_Mrs_D Nov 29 '13 at 22:54
  • Must admit I didn't think about the possibility of calling static methods on instances(and I'm not entirely sure I like the idea). Guess I have spent too much time in C# recently. Looking forward to see whether someone provides an answer. – MAV Nov 29 '13 at 23:37

1 Answers1

0

Speaking to C++

class Foo {
public:
    static  void staticFn(int i);
    virtual void virtFn(int i);
};

The virtual function is a member function - that is, it is called with a this pointer from which to look up the vtable and find the correct function to call.

The static function, explicitly, does not operate on a member, so there is no this object from which to look up the vtable.

When you invoke a static member function as above, you are explicitly providing a fixed, static, function pointer.

foo->virtFn(1);

expands out to something vaguely like

foo->_vtable[0](foo, 1);

while

foo->staticFn(1);

expands to a simple function call

Foo@@staticFn(1);

The whole point of "static" is that it is object-independent. Thus it would be impossible to virtualize.

kfsone
  • 23,617
  • 2
  • 42
  • 74
  • It is _not_ impossible to virtualize - I do not know _why_ they are not. The class object could have a vtable for that matter. I [read](http://stackoverflow.com/a/2223803/281545) that Objective-C and Scala support overriding of static methods. – Mr_and_Mrs_D Nov 29 '13 at 21:11
  • Yes - if you reduce the strictness of the definition of "static function", then it's possible to do. But in C++ it would not be possible. You either know the class at compile time, "Foo::staticFn()", or you don't, and if you don't, then what you have is an object, and what you need is a member function, because in C++ static member functions are basically syntactic sugar for non-class functions that actually have full member-like access. – kfsone Nov 29 '13 at 22:17