>
> Perhaps I'm missing something, but couldn't you take advantage of the
> numerous ways of constructing records, here, and do something like the
> following:
>
> (defrecord MyRecord [x y z])
> (defn ->MyRecord [x y z]
> (MyRecord. (* x 2) (* y 3) (* z 4)))
>
> (->MyRecord 1 2 3) ;=> #user.MyRecord{:a 2, :b 6, :c 12}
>
>
> So long as you stick with the convention that you always use the
> ->Record form, then this would be one solution. You could even create a
> macro to do this all for you:
>
> (defmacro defrecord-constructor [name args & body]
> `(do
> (defrecord ~name ~args)
> (defn ~(symbol (str "->" name)) ~args
> (~(symbol (str name ".")) ~@body))))
>
> (defrecord-constructor MyCoolRecord [x y z]
> (* x 2) (* y 3) (* z 4))
>
> (->MyCoolRecord 1 2 3) ;=> #user.MyCoolRecord{:x 2, :y 6, :z 12}
>
>
Yes, if I am the only programmer using the language, I can do that,
following some convention and etc. But I need to read other people's code
too. More importantly, I want the language to have good readability
built-in so the language itself get better and hence will help make all
other aspects of the language better too, which in turn will benefit me (I
want to use a good language and I don't want to waste my time on a language
that will get nowhere in a few years. Current popularity does not mean it
is sustainable). The logic is like this:
I make some small proposal -> proposal get adopted by the language ->
everybody gets a slightly better language -> development of all aspects of
the language get (slightly) faster/better -> I get a better and sustainable
language to use
Of course what I think is good may not really be good, or not generic
enough to justify being included into the language. Hence we need to
discuss and find out the pros and cons.But I hope people understand why it
is not proper to always say "hey, you can do it yourself, why bother
pushing it into the language?"
Honestly, I think this discussion/debate/feature request has little to
> do with the merits of OOP vs FP as concepts, and more to do with the
> general attitudes held by members of each community. The OOP world tends
> to espouse more of a "that's handled for me" approach whereas I've found
> FP circles to take the "I'll handle it" approach.
>
>
That's true. What frustrated me sometimes is that maybe Lispers are so
smart, they forgot some basic software engineering princples. They might
think all projects are a one or two-man shop, maybe because they themselvs
are so productive. That kind of attitude will hardly get an industry
strength language, and then they compain: why few people like my favorite
language? I suspect some people may even be delighted that the language
gets an elite status by not being so popular and well known.
And I also feel many of them are afraid new things (or patterns) to the
language will restrict their freedom and put some restrictions on the
future evolution. So the language always "keep the options open", making
certains things move very slowly.
> That said, what I like about Clojure (so far) is its willingness to try
> and find a middle ground. LISPs have notoriously failed to catch on
> because of their insular, built-from-scratch reputation, while OOP
> languages almost invariably end up wrapped in as much bureaucracy and
> configuration as actual code.
>
>
I hope this is the case. I do feel LISP itself is a good language in
principle. But it needs a little bit more common sense. It is a very smart
choice to develop a LISP dialect that sits on a host lanugage, so I hope
LISP will have a chance this time.
> Just my opinion, but I think if you tried something relatively
> unobtrusive like the above, and it caught on, you might some day find it
> incorporated into the main language. (After all, even the famous "let"
> started as a pattern that was made into a macro that ended up in almost
> every LISP in use today).
>
> Cheers,
>
> Josh
>
>
>
> --
> Joshua Ballanco
>
> ELC Technologies™
> 1771 NW Pettygrove Street, Suite 140
> Portland, OR, 97209
> jbal...@elctech.com <javascript:>
>
> P +1 866.863.7365
> F +1 877.658.6313
> M +1 646.463.2673
> T +90 533.085.5773
>
> http://www.elctech.com
>
在 2012年8月7日星期二UTC-4上午6时23分09秒，Joshua Ballanco写道：
>
> On Mon, Aug 06, 2012 at 07:32:42PM -0700, Warren Lynn wrote:
> >
> >
> > 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.
>
> Perhaps I'm missing something, but couldn't you take advantage of the
> numerous ways of constructing records, here, and do something like the
> following:
>
> (defrecord MyRecord [x y z])
> (defn ->MyRecord [x y z]
> (MyRecord. (* x 2) (* y 3) (* z 4)))
>
> (->MyRecord 1 2 3) ;=> #user.MyRecord{:a 2, :b 6, :c 12}
>
>
> So long as you stick with the convention that you always use the
> ->Record form, then this would be one solution. You could even create a
> macro to do this all for you:
>
> (defmacro defrecord-constructor [name args & body]
> `(do
> (defrecord ~name ~args)
> (defn ~(symbol (str "->" name)) ~args
> (~(symbol (str name ".")) ~@body))))
>
> (defrecord-constructor MyCoolRecord [x y z]
> (* x 2) (* y 3) (* z 4))
>
> (->MyCoolRecord 1 2 3) ;=> #user.MyCoolRecord{:x 2, :y 6, :z 12}
>
> Actually, this is pretty dirty...just something I threw together just
> now. I imagine that someone more familiar with Clojure scoping and
> binding rules could come up with something much more elegant (I'm fairly
> new to Clojure myself).
>
> Honestly, I think this discussion/debate/feature request has little to
> do with the merits of OOP vs FP as concepts, and more to do with the
> general attitudes held by members of each community. The OOP world tends
> to espouse more of a "that's handled for me" approach whereas I've found
> FP circles to take the "I'll handle it" approach.
>
> That said, what I like about Clojure (so far) is its willingness to try
> and find a middle ground. LISPs have notoriously failed to catch on
> because of their insular, built-from-scratch reputation, while OOP
> languages almost invariably end up wrapped in as much bureaucracy and
> configuration as actual code.
>
> Just my opinion, but I think if you tried something relatively
> unobtrusive like the above, and it caught on, you might some day find it
> incorporated into the main language. (After all, even the famous "let"
> started as a pattern that was made into a macro that ended up in almost
> every LISP in use today).
>
> Cheers,
>
> Josh
>
>
>
> --
> Joshua Ballanco
>
> ELC Technologies™
> 1771 NW Pettygrove Street, Suite 140
> Portland, OR, 97209
> jbal...@elctech.com <javascript:>
>
> P +1 866.863.7365
> F +1 877.658.6313
> M +1 646.463.2673
> T +90 533.085.5773
>
> http://www.elctech.com
>
--
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
