On Sat, Aug 4, 2012 at 8:33 PM, Warren Lynn <wrn.l...@gmail.com> wrote: > Simplicity is good, only when it is not too simple. Factory functions > denitely have its value, but for more dynamic cases (so you may even create > different record types based on the arguments). For static cases, why > scatter the factory functions here and there with certain name conventions > people may or may not follow? If they both achieve the same functionality, > don't you think grouping them in one place, with fixed naming pattern is > better? I thought OOP people long figured that out.
My point was that you don't need a factory function if there's no "construction logic" so the record alone - the data structure - is sufficient for a lot of cases. Similarly you can choose to use a "factory function" even if the underlying data structure is not a record. They are separate concepts and can be used in isolation. Simple, composable, you write just the code you need, no more. As Timothy pointed out, it's just functions and data, not objects. I think the fact that you can use defrecord to implement a Java interface is a bit misleading because it looks like a class implementation (and of course because it targets the JVM, the actual implementation _is_ a class) - when it's really just a data structure with some associated functions that operate on it. I hope that at least makes my position a bit clearer? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
