>> I have also found that clojure code lacks cohesion we hate objects so we are >> just going to throw everything into one large namespace and say we have >> none... In OO I might call this a god class? I don't know, I'm not sold >> yet... but I'll keep watching.
That depends. In OOP we might call it a "God Class" if it was 100 functions on a single mutable class. However, that's not what we're doing in Clojure. The analogy to OOP would would be a class with 100 static public members, and no private variables. This exact methodology is used in .NET for example: http://msdn.microsoft.com/en-us/library/system.linq.enumerable.aspx >> Now if you want to change a map so that :area which was previously an >> precomputed value to a deferred computation you now need to override ILookup I hear this argument at work dealing with Stored Procs in the SQL database. "If you don't let me do ad-hoc queries, then when you change the sproc, you're going to break all our code!". But the correct answer to this complaint is: "I won't". If you need to change area from pre-computed to defered execution, then you are changing the actual semantics of the code. In that case, yes, you will either need to define a different data api, or update all your old code to agree with the new computation method. Most of the time, if you have code in production, sticking with the first is the better route. During the day, I work on a fairly large C# codebase, and I see these same problems, but they are simply ignored by most .NET programmers. If I call Foo.getBar(). I haven't the foggiest clue where on earth it's going to get the data I want. It could be computing the value, or simply returning a private variable, or it could be going to Mars to gather a soil sample and use that in its calculation (blocking me until it returns). That's one of the benefits of the "everything is a map" method. I know that calling (:bar data) is going to return almost instantly. You can re-write your data server to involve Mars trips, but once the data is in my program, my code will remain snappy, no matter how long it took to compute that data. So I guess what I'm saying is that if you're deciding to switch area from pre-computed to lazy execution, that's such a major change semantically that you better reevaluate your code before simply abstracting it and calling it a day. But then again, I'm biased. I deal with so many layers of abstraction at my day job sometimes I just want to stand up from my desk and shout "A hashmap! My kingdom for a hashmap!". Timothy Baldridge -- 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
