3 ms·

"In case you're (somewhat) unfamiliar with OOP terminology, polymorphism is a pretentious name for the concept of late binding." Actually, they are two related

"In case you're (somewhat) unfamiliar with OOP terminology, polymorphism is a pretentious name for the concept of late binding." Actually, they are two related, but different concepts. Polymorphism generally refers to http://en.wikipedia.org/wiki/Subtype_polymorphism http://en.wikipedia.org/wiki/Subtype_polymorphism but there are other types. In short, it involves virtualizing an interface. Late binding, aka "Dynamic Binding", on the other hand, makes no assumption of an interface and does not necessarily imply polymorphic behavior.

Dn_Ab 16y ago
Excellent point there are many types of polymorhism (hehe) ad hoc, subtype etc. As a functional programmer when I hear polymorphism I default to parametric polymorphism. This guy is not talking about polymorphism at all but instead the limitation of late binding via dyanmic/single dispatch.
- bad_user 16y ago
  As a functional programmer when I hear polymorphism I default to parametric polymorphism. This guy is not talking about polymorphism at all but instead the limitation of late binding via dyanmic/single dispatch. It doesn't matter what type of polymorphism you're referring to, all it matters is what polymorphism does ... the ability of a certain piece of code to run with any data types provided they implement some kind of contract. Late binding / runtime dispatching is giving you an implicit polymorphism that's more powerful that all those types you mentioned since the contract is also implicit. You are right that Stevey talks about the limitations of single-dispatching. Multimethods are designed precisely for the problem he describes. Multimethods are very powerful, problem is they come with great runtime penalty and there aren't too many use-cases for multimethods. Otherwise, because in both Python and Ruby you can override the dispatching mechanism and generate code at runtime, you can add multimethods to them. For example in Python you can use the "peak.rules" package: http://pypi.python.org/pypi/PEAK-Rules http://pypi.python.org/pypi/PEAK-Rules Then you don't need to add methods to every possible Callee type, you just add a multimethod on (Caller, Callee) + a generic one on (Caller, object) which returns a default for unknown cases. It's cleaner because you can add that multimethod anywhere (either in the Caller's package or in the Callee's package) and it also doesn't break encapsulation, and without the runtime penalty I would prefer it to a big switch ... simply because you might not have the ability to modify the Caller's package.

Dn_Ab 16y ago

Excellent point there are many types of polymorhism (hehe) ad hoc, subtype etc. As a functional programmer when I hear polymorphism I default to parametric polymorphism. This guy is not talking about polymorphism at all but instead the limitation of late binding via dyanmic/single dispatch.

bad_user 16y ago
As a functional programmer when I hear polymorphism I default to parametric polymorphism. This guy is not talking about polymorphism at all but instead the limitation of late binding via dyanmic/single dispatch. It doesn't matter what type of polymorphism you're referring to, all it matters is what polymorphism does ... the ability of a certain piece of code to run with any data types provided they implement some kind of contract. Late binding / runtime dispatching is giving you an implicit polymorphism that's more powerful that all those types you mentioned since the contract is also implicit. You are right that Stevey talks about the limitations of single-dispatching. Multimethods are designed precisely for the problem he describes. Multimethods are very powerful, problem is they come with great runtime penalty and there aren't too many use-cases for multimethods. Otherwise, because in both Python and Ruby you can override the dispatching mechanism and generate code at runtime, you can add multimethods to them. For example in Python you can use the "peak.rules" package: http://pypi.python.org/pypi/PEAK-Rules http://pypi.python.org/pypi/PEAK-Rules Then you don't need to add methods to every possible Callee type, you just add a multimethod on (Caller, Callee) + a generic one on (Caller, object) which returns a default for unknown cases. It's cleaner because you can add that multimethod anywhere (either in the Caller's package or in the Callee's package) and it also doesn't break encapsulation, and without the runtime penalty I would prefer it to a big switch ... simply because you might not have the ability to modify the Caller's package.