On Mon, Dec 30, 2013 at 12:45 PM, 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. > That would then suggest that the Expression Problem is a problem that only OOP has. ;) -- -- 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.
