Maybe Erlang is OO after all?
Sat Aug 23 03:39:28 CEST 2003
Chris Pressey wrote:
> Polymorphism as it's usually promoted elevates the semantic<->syntactic
> mapping to a human (read: fuzzy) level while obscuring the actual
> working detail semantics. i.e., suddenly X.play() can have wildly
> different resource requirements depending on whether X is of type Movie
> or of type GameOfNim. And don't even get me started on dog.bark() vs.
You can control this kind of problem using assertions (or, more
precisely: using the Design by Contract rules).
In a nutshell, Design by Contract says:
In the superclass, every routine should have preconditions and
postconditions that adequately define the semantics of that routine.
In the subclass, any redefinition must be compatible with these
assertions (the actual rules are more precise, but that's the gist of it).
GOOD OO software is written with Design by Contract in mind.
(A fuzzily-worded version of DbC is known as the "Liskov Substitution
Principle", in case anybody wants to do a Google search.)
My experience with a language that supports DbC directly is that this is
powerful enough to prevent idiocies like Dog.bark vs. Tree.bark (not
that anybody in his right mind would make Dog a subclass of Tree or vice
versa - this kind of problem is far less common than one might think).
More information about the erlang-questions