Hacker News Reader

Comment by gizmo | Hacker News Reader

They get the definition of polymorphism wrong, because their definition ("ability of one method to have different behavior depending on the type of object it is being called on / object passed by parameter) is also met by compile time function overloading. Their example, where you have a customer integer class that is capable of dealing with both other integer arguments and floats is pretty poor.

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time.

View on HN

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time.

At least in C++ world, it's not true. There things like compile time polymorphism, and run-time polymorphism.

And by the way, why do you think polymorphism should be based on run-time data? simpler things can be achieved at compile time with static analysis, which many OO languages do [C++, and Java for sure].

Just because it's simple to do, you don't have to declassify it from being polymorphic.

Whenever I think of polymorphism in C++, I think of base pointers, virtual functions and the vtable. I guess my mind just puts run time and compile time in separate boxes.

Broader definitions than yours are in common use. You might find this classic paper: http://www.is.pku.edu.cn/~qzy/plan/lits/FundamentalConceptOf... and this updated survey: http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf interesting.

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time.

I'm not sure that's always true. Or at the very least seems language dependent.

Yeah, Java doesn't do multimethods (i.e., method dispatch based on runtime argument types).

If Class X has two methods:

  void foo(Object i);
  void foo(Integer i);

then:

  Object test = new Integer(4);
  X x = new X();
  x.foo(test);

will invoke 'void foo(Object o);' based on the compile time type of test.

Java does do dispatch based on the runtime type of X - but it is quite limiting once you are used to having proper multiple dispatch at your disposal.

(caveat: not in front of a javac - this is from memory).

You're right. It calls 'void foo(Object o);'

    import junit.framework.TestCase;
    
    public class TestMultimethods extends TestCase {
        public void test() {
          Object test = new Integer(4);                                        
          X x = new X();                                                       
          assertEquals(x.foo(test), "foo(Object)");
        }
    }
    
    class X {
        String foo(Object i) { return "foo(Object)"; }
        String foo(Integer i) { return "foo(Integer)"; }
    }

"Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time."

I think the emphasis on runtime data is a mistake. It would be possible to imagine an static, OO language which has polymorphism implemented using static analysis - perhaps in limited circumstances.

(I agree with your point about their definition also being met by overloading)

Actually, polymorphism is when two or more clearly different phenotypes exist in the same population of a species — in other words, the occurrence of more than one form or morph. </tounge-in-cheek>

Polymorphism is certainly not a very well defined notion. Personally, I think the best answer would be "I don't know a precise definition, I've heard it mean different things based on context, for example...".

Any definition of polymorphism should at least mention something about the method that is invoked depends on runtime data, and is not resolved (or known) at compile time.

Yes

  class A { ... f() ... }
  class B extends A { ... f() ... }
  class C extends A { ... f() ... }
  A x =  ...  // a B object or a C object
  x.f()

is polymorphism if anything.

> They get the definition of polymorphism wrong, because their definition ... is also met by compile time function overloading.

That doesn't make the definition incorrect; there are many types of polymorphism.

Function overloading is an example of ad-hoc polymorphism; generics is an example of parametric polymorphism; and inheritance is an example of inclusion polymorphism.

Reply on news.ycombinator.com