> Of course you don't need OO to do polymorphism, and I'm fairly sure > that OO doesn't do polymorphism the best way, but in my estimation the > main reason "classic" OO is so popular is that it provides a very > concrete way to do polymorphism easily.
At the risk of going off on a bit of a tangent: My experience with teaching OO to university students (and watching my own class learn it) suggests that polymorphism -- at least, as presented by C++ and Java -- is the hardest concept for beginners to grasp. Encapsulation and some (usually erroneous) notion of 'modeling the world' would seem to be the most obvious improvements over structured programming, and beginners pick those up easily. When you present a scenario of some object representing a bank account, "owning" its balance and providing an interface to access it, OO seems a natural fit to the problem. Polymorphism builds on that, yes, but one could have a useful OO system without it (e.g., the various approaches to OO in C, such as putting function pointers in structs, or prototype-based OO systems). I suspect that students' difficulty with "traditional" OO polymorphism has something to do with having to hold the inheritance hierarchy in their heads while also looking at the instance, and figuring out what will happen. At that larval stage it's a lost cause to dive into virtual function tables :) I'd be interested to see how Clojure's multimethods -- which pull out the dispatch function into a concrete thing -- fare by comparison. As with a lot of things, having a REPL there and being able to call the dispatch function on various inputs would be a massive aid to understanding. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
