James Reeves <ja...@booleanknot.com> writes: >> > Yes, Clojure pretty much rejects the idea of uniform access. > > >> I don't think it does. I think it just does not support it which is a >> somewhat different thing. >> > > I thought it was pretty clear that Clojure prefers data over APIs. The > uniform access principle is about preferring APIs over data, which seems > counter to Clojure's ideology.
The uniform access principle is about having uniform access to data and APIs. It's not about prefering one or the other. > Still, although my example might appear irrelevant to Clojure in >> general, I don't think it is. Clojure's current docstring support is not >> very good (and there was a thread here about it not long ago). It would >> be nice to have something richer. For really rich documentation, >> maintaining the docstrings is a different file might make sense. Clojure >> can support this at the moment, but only in the way that I have -- the >> var metadata could be updated at load time. What it cannot do (easily) >> is support lazy loading of the file documentation at the point of first >> use, because the decision was made originally that :doc metadata is a >> value and is NOT computed. >> > > There's no reason why you have to use the :doc metadata for that. Just > write another function that takes a var and spits out some documentation. Yes, which is what I have done, of course. Now it won't work in any IDE which looks for the docstring as :doc metadata. It is totally unextensible. I do not think that this is good. >> > The largest systems we've developed, including the web itself, are data >> > driven. >> >> Interesting. So, if you resolve http://www.clojure.org, is this data or >> is it computed? >> >> I don't think you can tell. The web supports the Uniform Access >> Principle. > > > The response may be computed, but once it's sent to the client it's > immutable data. Well, that's the point, you cannot tell. So, for example, I can provide a website implemented over a relational database. Or I can serialize it out as static files. Or I can add a caching layer which serializes lazily, and redoes every hour. > The response returned has no inherent API associated with it. That sort of depends on the response. > To put it another way, consider the function: > > (defn build-user [first-name last-name] > {:first-name first-name > :last-name last-name > :full-name (str first-name " " last-name)}) > > Like a website, a function may perform computations, but its return > value is immutable data. Would you say the above conforms the the > Uniform Access Principle? As I said at the beginning, it is possible to achieve UAP by making *everything* a function. So, we can automatically achieve UAP by ONLY using functions and never values. So consider for example, this case. (:doc (meta #'concat)) The return value of this expression can never be computed (short of reimplementing ILookup or IMeta which, of course, we could do). On the other hand ((:doc (meta #'concat))) could be computed or not, since the function returned could just be returning a value. So, the latter supports the UAP, the former doesn't. In fact, this is how I squared the circle in my case. I changed data-factory to (data-factory) In most cases the data-factory function just returns a constant value, but it can use computation when I choose. Phil -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
