Adding complexity to a language on the basis that it fits your perception on what is easier to read while there is already another alternative covering several other use cases is the central issue here.
My reluctance (or allergy as you may suggest) about OOP is toward the popular implementations that are insanely verbose. Design "patterns" exists by themselves, no need to enforce them in language constructs. Referring to OOP as an inspiring practice is far from what it became these days specifically in terms of efficiency. Fans of bureaucratic processes however are still legion and popular OOP implementations are more in line with that, it takes at least twenty steps to lift a finger. That maybe great to increase professional revenues however it does little to produce systems with decent code base sizes and complexity. Implementing a constructor as you suggest increases verbosity without a significant return compared to functions however tempting it may look like, it seems to be a small addition in a limited scope, .... This practice leads to fragmentation of features and at some point in time it becomes impossible to turn around your language to meet new situations, there's a big elephant on your back that you have to carry around. We should rather take a step back and look at this under new lights. What features will it provide ? What is the added value compared to what exists ? How flexible will it be and will it be able to evolve ? How much luggage are we adding and is it worth the benefits ? Perceived easiness is not a benefit, it's a perception. This will die when your body decays, the construct will survive you. If you go back in this thread, most of the answers have been provided to the above questions. Luc P. > > > On Sunday, August 5, 2012 7:23:55 PM UTC-4, Luc wrote: > > > > You have been referring to OOP several times in your posts, the kind of > > patterns > > we are talking about are these: > > > > http://en.wikipedia.org/wiki/Software_design_pattern > > > > These are the kind of design patterns OOP has been fond of in the last ten > > years. > > Java/C# and cie have been implementing/following these closely. > > > > You need an army of people to create/maintain Java apps, we can look back > > at it > > after ten years. It's insane. > > > > Excuse-me but I cannot find this inspiring at all. Borrowing from OOP in > > this context and > > adding it to Clojure to mimic some of this low level stuff is going the > > wrong way in my > > opinion given that more generic bolts and nuts are already available in > > Clojure. > > > > Defrecord/protocols are not classes/interfaces. > > The fact that they are implemented as such is irrelevant, it's an > > implementation detail. > > > > This notion of "constructor" is something you are borrowing from an alien > > world (OOP) > > and you want to patch this in defecord invoking arguments from the OOP > > world to > > justify it. > > > > Excuse-me again but I have a hard time to follow your rational. > > > > To me it's like trying to breed a mouse and an octopus. I do not even want > > to > > think about the end result. I bet on the octopus... > > > > There are certainly other avenues more innovative to explore before adding > > constructors to defrecord. > > > > Luc P. > > > > > > > At least we are back to the track of right/wrong patterns/bolts instead of > no patterns at all. :-) Factory function itself is already a pattern, by > the way. > > Maybe I should not mention "OO" so many times. I am still puzzled (and > amused, and somewhat dismayed) why this word has become so sensitive in the > community. I list two or three reasons I think why the constructors are > helpful. Now just pretend for a moment OO never exists, do you still think > those reasons are good reasons? Maybe yes, maybe no, but my rational is > clear, without the need to referring to OO at all. I mentioned OO because I > thought that will quickly explain what I want since everybody knows what a > constructor is. But the allergy is obviously more severe than I thought. > > For people who think those reasons are not good, it will be more > interesting to show what exactly the harm is, instead of more or less > simply say "Woh, it involves the word OO? bad". > > Also, I admit this stuff is boring, not anything as fancy as the new > reducers, but we need to deal with boring stuff far more often and hence I > feel it is worth a discussion. > > > > > -- > 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 -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- 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
