A) protocols provide benefits that multi dispatch don't like performance....
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
options. 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 obscure/unmaintanable code.
The approach in the Clojure implementation is to provide you the nuts and bolts
to provide your own implementations. It maintains flexibility and open doors
to future needs and other carefully chosen nuts and bolts.
This is not to say that records as they exist will never change but your point
about
standardizing patterns is wrong. Providing necessary nuts and bolts is the
prime target,
adding patterns is not.
Luc P.
>
>
> > 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.
> >
> >
> I don't see my proposal above requires more code writing. It just captures
> the pattern better.
>
> When it comes whether we "need" or "not need" something, again my view is
> not to judge by checking whether the language will "work" without
> something. Also, simplicity and composibility is not the golden standard
> either. It that is so, again, assembly language meets those "standards"
> quite well (it works, hence does not need anything extra. It is simple, and
> you can compose it however you want). Ideally, the language should capture
> common abstraction and patterns, but also expose enough simple and/or
> composable raw materials for not-so-common cases.
>
> To make an analogy, my remote control (a programmable universal one) has a
> "watch TV" button. That button can be programmed to turn on/off my TV and
> my receiver simultaneously (basically send two separate signals to the two
> devices). But it also has separate buttons just for the TV and the receiver
> respectively. You don't "need" it, but isn't it quite useful, assuming
> watching TV is a high probability common use case?
>
> Another example, since we already have multi-function, why do we need
> record and protocols? Multi-function can to whatever dispatching you want.
> As one person mentioned, he just always put ":type" into his maps and use
> multi-function. But it seems many people see this common pattern and we
> have standardized single type-based dispatching now. Some people may claim
> records are *only* for Java interop, but we have generic :gen-class and
> other things, right? So we don't "need" it just for Java interop.
>
> One benefit of capturing common patterns in a language is the language will
> standardize it so the code will be more readable. As I mentioned before in
> another post, our code not only needs to make things happen on a computer,
> but also needs to communicate how that magic happens so yourself and other
> people can understand it and maintain it. Sometimes, the pattern is so
> trivial, the main benefit actually comes from the standardization. Just
> like the shape of electricity outlets, does it matter so much which shape
> it should be? Probably not, What it matters is we all agree to use the same
> shape so I don't have to bring an adapter when I travel to another country
> (unfortunately that is not the case).
>
> 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.
> >
>
> My use of terminology is not good, sorry for that. My "object" here is more
> like "entity", not exactly the common OO objects with data and functions
> tightly bound together.
>
>
> --
> 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
