C# extension methods are not polymorphic either. For example, casting a object to a parent type will cause a different extension method to be run. This is not the case in normal polymorphism, or for protocols (Clojure is a dynamic language, so casting doesn't exist anyways).
You're right, you can (and I have) implement protocols in almost any language, even C++. It's just much more ugly and unidiomatic in c++. And what Cedric says is correct, encapsulation is rarely a good thing, and inheritance is overrated. Since Clojure's extend function accepts a hashmap of method names and functions, you can easily build "stock implementations" by putting standard implementation functions into a hashmap and then assoc'ing in new functions to "override" behavior. On Mon, Dec 30, 2013 at 10:31 AM, Cedric Greevey <cgree...@gmail.com> wrote: > On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli < > kiuhn...@gmail.com> wrote: > >> On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: >> >>> On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge >>> <tbald...@gmail.com>wrote: >>> >>>> Not mentioned in Cedric's post are two other important things: >>>> >>>> Protocols can be extended to existing types. >>>> >>> >>> These are important for the Expression Problem, but not for the OP's >>> query as originally stated, which simply asked for the contrast with >>> overloading. That contrast is dynamic vs. static dispatch. As for C++ being >>> able to solve the Expression Problem and thus being "equally powerful", >>> well, both languages are also Turing complete. But which will generally let >>> you be more expressive, with less ceremony and verbosity? Which has >>> templates and macros that are unhygienic and a bugbear to work with, and >>> which has macros that are very safe and clean? >>> >> >> What I was saying was more subtle. If C++ can solve the Expression >> Problem the same way Clojure does, why do you say that Clojure's solution >> is acceptable whereas C++ programmers don't accept the same solution for >> C++? That's simple: external functions are not real methods. So we're >> accepting Clojure's solution because Clojure doesn't support real methods >> and objects, but we're rejecting the same solution in C++ because C++ >> *does* have real methods and objects. Isn't that absurd? >> > > I think you'll need to define what you mean by "real methods and objects", > and in what way the word "real" is supposed to be establishing a contrast. > A contrast with what, exactly? > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
