I think you have read too deeply into my thoughts on reserving the first argument of a function. I haven't actually written any polymorphic functions relating to this.
Really, the take off point for me is being able to operate on an object by implementing it as a map of functions and data. That is to say, making objects data. Implementing multiple inheritance becomes trivial and without having to define any classes or any interfaces. And with full support for circular references without needing to do declares. What I like about it is that I get separation of concerns and maximal reuse without, I suspect, the usual usage coupling. The small maps which define traits can even participate in the lifecycle of the aggregate, so they start taking on the characteristics of components. My biggest problem with writing code over the decades has been the constant desire to do rewrites--which are costly and devastating in their impact. That is *why *I am fascinated with this approach. A second *why *is that when I have clear separation of concerns and the pieces of code can be easily tested independently, documentation becomes clearer and more fun to write. And keeping code fun is a critical driver for open source. On Mon, Nov 23, 2015 at 9:24 PM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > So I feel compelled at this point to ask..."why?". The whole point of > functional programming in Clojure is to de-couple state from data. When you > need polymorphic dispatch on the contents of a map, you have access to > multi methods. Sure this is a fun thought experiment, but I don't > understand the design goals. It's a fairly verbose way to write more > complex code to accomplish what we already have good tools for > (protocols/multimethods, etc). Maybe I'm missing something. > > Timothy > > On Mon, Nov 23, 2015 at 7:15 PM, William la Forge <laforg...@gmail.com> > wrote: > >> James, when I used the term mixin I was referring to a map that acts like >> a trait that gets merged into a larger map. You would define several such >> smaller maps that can then be used in various combinations to compose >> "objects". The identity of the composite object (this) is the map which >> holds the merged contents of the smaller maps. I.E. The entries in the >> smaller maps get copied into the larger map. >> >> When executing functions held by a map, the last parameter is always the >> map itself, i.e. the "this". On the other hand, when placing closures into >> the map, the self reference is no longer needed as it is implicit in the >> closure. But this means that a closure can only reference the contents of >> the map when the closure was created, while a function can reference any of >> the contents of the map passed as its last argument. >> >> Why did I make the map reference the last argument for functions held by >> the map? So that we can do type polymorphism on the first argument passed >> to the function. But we should make an exception to this. To facilitate >> threading, functions which return an updated map should take that map as >> the first argument. But that is an API change and needs to wait for release >> 0.6.0. >> >> -- >> 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/d/optout. >> > > > > -- > “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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/7Q7QvlSUGL4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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/d/optout.
