On 20 October 2014 14:02, Phillip Lord <phillip.l...@newcastle.ac.uk> wrote:
>
> The uniform access principle is about having uniform access to data and
> APIs. It's not about prefering one or the other.
>

Right, but Clojure *does* heavily prefer data over APIs, and therein lies
the conflict.



> 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.
>

Clojure prefers "simple" solutions over "easy" solutions.

Unrestricted polymorphism and universal access would make solving this
problem easier, but they also create more complexity.

Or to put it another way, rather than trying to shoehorn a solution into a
system that wasn't built for it, we should design a new system around the
desired solution. In the case of documentation, the most obvious approach
is to decide on a new protocol all IDEs can implement.


> 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.
>

Yes, and so can a function. Clojure doesn't say, "you shouldn't compute",
it says, "you should separate computations and data".

I suppose it's possible to build a service where every value lookup
requires hitting an external server, but no-one sane builds a web service
like that. Latency concerns alone mean that data and computation need to be
separated in distributed systems.



> > The response returned has no inherent API associated with it.
>
> That sort of depends on the response.
>

I suppose one could design architecture around passing around executable
code that's executed in a sandbox by the client, but see my previous point
about sane design.



> > 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.
>

The point I was trying to make was that computed values (such as those
produced by a web server) do not necessarily imply UAP.

I don't disagree that UAP has some benefits, but it comes with a huge
number of tradeoffs. Given that the problem it tries to solve is, in my
experience at least, exceeding rare, it really doesn't seem worth the
additional complexity.

- James

-- 
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.

Reply via email to