> 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
