" If the Expression Problem consists in extending classes then non-OOP languages must be excluded because they don't have classes."
No offense intended, but that is an incredibly wrong statement. Let's look up the official definition of the expression problem (via wikipedia): "The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)." The easiest way to solve this is via something like clojure's multimethods. However this is probably not the fastest way as it involves a lot of runtime computation. However, multiple dispatch has long been the defacto standard in solving the expression problem. Everything else pales in comparison to the raw flexibility of multimethods. Another way is via something like monkey-patching, but that has drawbacks of name collision. Or someone can go with the janky brute force visitor patter, and that involves a ton of boilerplate. What clojure's protocols allow is the addition of namespaced polymorphic functions that can be extended to any type. Here's an excellent article that goes over the flaws in OOP that make this problem much harder than it need be ( http://www.ibm.com/developerworks/library/j-clojure-protocols/ ) Timothy Timothy On Mon, Dec 30, 2013 at 10:45 AM, Massimiliano Tomassoli <kiuhn...@gmail.com > wrote: > On Monday, December 30, 2013 6:27:05 PM UTC+1, Cedric Greevey wrote: > >> On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli < >> kiuh...@gmail.com> wrote: >> >>> On Sunday, December 29, 2013 10:11:47 PM UTC+1, tbc++ wrote: >>>> >>>> Not mentioned in Cedric's post are two other important things: >>>> >>>> Protocols can be extended to existing types. For example: >>>> >>>> (defprotocol IType >>>> (type-as-string [x])) >>>> >>>> (extend-protocol IType >>>> String >>>> (type-as-string [x] "string") >>>> Integer >>>> (type-as-string [x] "integer")) >>>> >>>> => (type-as-string 42) >>>> "integer" >>>> >>>> Here we are adding new methods to "sealed" closed classes that already >>>> exist in the JVM. We never modify these classes, we simply extend our >>>> protocol to them. >>>> >>>> Secondly, all protocol functions are namespaced. This allows us to >>>> extend classes without fear of overwriting existing methods. This then is >>>> more powerful than monkey patching in Ruby or Python as the resulting >>>> method is more like 42.user_type-as-string(). Clojure's namespace system >>>> then allows you to refer to one method or the other just as you would any >>>> normal functions. >>>> >>> >>> You're not really adding methods to classes in Clojure. You're just >>> defining external functions. Can you make them private or protected? In my >>> opinion, the Expression Problem in FP and OOP are two different problems. >>> In FP you can "solve" it more easily because you use pseudo-classes which >>> don't behave like real classes at all. The proof of this is that any >>> sufficiently dynamic OO language can solve the problem the same way Clojure >>> does just by using classes with no methods and by using overloading >>> resolved at runtime. >>> Of course, you don't do that in OOP because you want to work with real >>> classes. For instance, C# has extension methods which let you "add" methods >>> to existing classes without any recompilation. Problem solved? I don't >>> think so. Extension methods are just static functions that emulate the >>> behavior of instance methods, but without any kind of encapsulation and >>> possibility of inheritance. >>> >> >> Encapsulation is less important without a lot of mutable state lying >> around, and remains important mainly at module boundaries, not "class"-like >> boundaries, where code belonging to different programmers comes into >> contact. If I change the internals of doohickey A and that breaks doohickey >> B inside the same module, I can fix B, and I know how to, and I know to do >> so as soon as I change A. It's when someone else changes doohickey C in a >> different module that I'm in trouble if I'm depending on the internals, but >> then hopefully there's an encapsulation boundary at the module boundary >> between my stuff and doohickey C. >> >> As for inheritance, it's *highly* overrated, complecting as it does >> composition and polymorphism. We Clojurians tend to keep those separated, >> and as a result protocols are purely about polymorphism while composition >> is dealt with in some orthogonal way. >> > > That's your opinion and I respect that. Maybe someday I'll come around to > seeing things your way as I delve into Clojure, but I doubt it :) > But I still think that we can't compare OOP and non-OOP languages w.r.t. > the Expression Problem. If the Expression Problem consists in extending > classes then non-OOP languages must be excluded because they don't have > classes. We can't put datatypes and classes on the same level. They're just > different things. > > -- > -- > 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.
