My reluctance (or allergy as you may suggest) about OOP is toward the > popular > implementations that are insanely verbose. > > Why is it insanely verbose? Just look at my example:
(defrecord MyRecord [x y z] (make-record [arg1 arg2 arg3 ...] ...)) (make-record MyRecord arg1 arg2 arg3 ...) How is that more verbose than (defrecord MyRecord [x y z]) (defn make-MyRecord arg1 arg2 arg3...) (make-MyRecord arg1 arg2 arg3 ....) I just fixed the name and shuffled things around. 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. > > I agree a language cannot support all possible patterns. Some of them come up later after the language is designed (but often those patterns, if deemed good, are put into the design of new languages). But I disagree all patterns are like that. Actually a major differentiating factor among the languages are the patterns (some all it "paradigm") they support. Again, I probably should not have referred to OOP. Can we just evaluate the proposal itself based on its own pros and cons specifically? I am glad this post actually is moving into that direction. How about I don't call them "constructors", I just call them "inlined factory functions". :-) > 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. > > That might be true with certain OO languages, after all, any crappy language can all themselves OO. But I don't see the extra steps in my proposal compared to the regular factory functions. > 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. > > Now let's get to the specifics. > What features will it provide ? > No feature that will make the language do more magic things. The language still works without it. But I hope we are aiming higher here. > What is the added value compared to what exists ? > 1. Readability. This is the one I care about most. I can clearly see along with the definition of the record what is the legal ways to create the record. I don't need to guess whether the creation function will be make-myrecord, make-MyRecord, new-record, create-record, or just a plain function (foo ...). I do a (doc MyRecord) and will see all the doc strings for its constructors. It groups things logically. If you don't care about readability, then we don't have a common ground for further debate. And if this is the dominant view of the designers/core members, then the language will forever be a toy/niche language. Geniuses may not care so much about readability (Actually, I think even Geniuses should care, because you need average guys to work for you, but Geniuses are beyond me). Just call me dumb and the debate is over. :-) 2. The compiler may do a bit better job in error checking because it knows the constructors are supposed to return MyRecord, not anything else. 3. Certain macros or higher order functions may be easier to write because of the naming regularity of the constructors. I don't have a good example at hand (silly examples won't convince anybody). So you need a bit imagination of your own here. > How flexible will it be and will it be able to evolve ? > It won't be as flexible as a free form factory, I am sure. But I don't think that kind of flexibility is needed all the time. So far for myself, 90% of the time I just need to create a plain record. Don't need any extra flexibility. If I do need it later, factory functions are still available, right? I don't know how well it will evolve. My view is: unless somebody can point out it will evolve into something bad, why do we care? We can have its benefits now. > How much luggage are we adding and is it worth the benefits ? > > Here I need people's help/feedback. Show me the harm so we can balance things. Perceived easiness is not a benefit, it's a perception. This will die when > your body > decays, the construct will survive you. > > Show me the difference between perception and reality if there is a gap. For example, can you show that the benefits are not real, and the harm is a lot larger than I think? > If you go back in this thread, most of the answers have been provided to > the above > questions. > > > Actually I don't see the answers to the core question: where is the harm? Luc P. > > -- 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
