On Jun 17, 2012, at 10:45 AM, Vinzent <ru.vinz...@gmail.com> wrote: Yes it is... emails was not the best example in this case.. think the > "area" example instead as this is single value rather than collection. >
Well, I thought we've already came to the agreement that area is a (polymorphic) function and it has nothing to do with structure of your data, no? Yes, what I am also saying is that width, height, radius etc may also be functions, if they are used by the domain they are should be a function. If they are not used by the domain they are an implementation detail and should not be accessed via keywords except of course by the single function that provides the seem. Lazy sequences also introduce additional problems... they maybe "realized" > when bindings are no longer in effect which causes all sorts of non-local > errors with stacktraces that are completely non-intuitive. > Use bound-fn and similar tools to preserve the context. Use contract programming <https://github.com/dnaumov/clojure-contracts> to get rid of ugly stacktraces :) Anyway, these are other problems not related to the topic. Yes there is that, but this is doesnt resolve all problems with bindings... Perhaps a different topic, but arent we already off topic :) Yes, always access a map value via a function, this provides a "seam" (see > Feathers, Working Effectively with Legacy Code > http://www.informit.com/articles/article.aspx?p=359417) where alternative > behavior could be introduced. Keywords are functions, but their behavior > cannot changed therefore they do not make for useful seams. The data still > needs to be stored some where so you will have maps and will still need to > use keywords to access that data... > Well, "accessing a map value via a function" is what object-oriented programming is about. So your concern is about the fact that clojure isn't object-oriented? I thought you was talking about using functions to model all other data structures, which is a good idea in theory, but is not very practical. but that keyword usage should be in only one place so that when you do > change the data structure eventually you will need to only update that one > function. > Changing data structure == changing API. If you change an interface in Java how many updates you'd have to do? Data structure is an implementation detail... interfaces are contracts, if the data representation changes in OO you need only change one class... In clojure, you need to change every usage. This is speaking from first hand experience when I made trivial changes that would be a one liner in java took hours and introduced simple bugs, wring usage, typo whatever. This is exactly the point of my post, if you wrap keywords and treat them as one does properties this could be a one liner in clojure too... I disagree. I don't think OO has failed us...MOST software is written in > OO languages. > A million lemmings can't be wrong. Sure. I'm not blindly advocating the use of simple abstractions just because that what some/many OO programmer suggests is best practice... but because personal experience has given me enough conviction to believe they add value even if they add a few LOC... And that it is worth arguing about a bit... even if this means I am not "following" idiomatic clojure practices that I disagree with. I don't agree with all OO practices either..mutable collection types, excessive over engineering... All patterns have some trade offs, but one LOC for a seam is well worth it imo. > Lisp and various functional languages are much older than OO, yet were not > widely adopted for commercial use. > That's not true - they were. > I'm not saying OO is perfect or that there is no room for improvement, > thats why I tried clojure in the first place, but perhaps OO has been far > more successful then you give it credit for and certainly more successful > in practice then these so called "academic" languages. > Java is successful for commercial reasons, not because it's the best language ever written. -- 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 -- 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
