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. > > > B) I said I hate the pattern word, let me say it bluntly, elaborate > > patterns have the unique > > property of fossilizing a language as soon as you start to modify the > > language > > to support them. Especially complex ones. > > It kills evolution the day you need to meet other needs, > > you have crippled your implementation with patterns and it no longer > > can be > > turned around to accomodate future needs. > > It's the same with a lot of frameworks, they to go through some heavy > > twists > > after a number of years just to,keep up. > > > > C) patterns do not improve readability, they just narrow the readers and > > writers > > optionsmy of codes. Readability is more a factor of your abstraction > > choices and > > the cleanleaness of your implementation which has little to do with > > rigid language implemented patterns. A bad choice of pattern will > > always > > yield s.obscure/unmaintanable code. > > > > > > > I think our difference is minor, what you called "bolts and nuts", I call > them "patterns". Our difference is what kind of bolts and nuts should be > included in the language. You may argue my proposal is not a good pattern > (or bolts/nuts), but I mean, are you sure you don't like any patterns? Is > multi-function a pattern? Is FP a kind of pattern? Is namespace a kind of > pattern? I truely believe only assembly does not give you any patterns (but > maybe the register name shows some patterns, so better just use 0s and 1s). > > -- > 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
