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 <javascript:>> 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.
