On Mon, Dec 30, 2013 at 12:13 PM, Massimiliano Tomassoli <kiuhn...@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. -- -- 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.
