7

My background is Ruby, C#, JavaScript and Java. And now I'm learning Clojure. What makes me feel uncomfortable about the later is that idiomatic Clojure seems to neglect the Uniform access principle (wiki, c2) and thus to a certain degree encapsulation as well by suggesting to use maps instead of some sort of "structures" or "classes". It feels like step back. So a couple of questions, if anyone informed:

  • Which other design decisions/concerns it conflicted with and why it was considered less important?
  • Did you have the same concern as well and how it end up when you switched from a language supporting UAP by default (Ruby, Eiffel, Python, C#) to Clojure?
  • please add uniform-access-principle tag who has enough reputation. – Alexey Oct 15 '13 at 0:35
  • 10
    Because clojure isn't object oriented. UAP is principly meant to distinguish between methods and fields. Clojure has no objects, everything is either data or a function. So access is uniform. – Daniel Gratzer Oct 15 '13 at 2:44
  • @jozefg, you just replace methods with functions and fields with hash keys and you have the same case for Clojure. And (:f x) and (f x) are different and access is not uniform. So your statement is not an argument. – Alexey Oct 15 '13 at 12:33
  • 6
    youre missing the point, functional programming languages dont have "smart data". Abstraction comes through functions. Define a function some-key and change it however you want if you want to access it differently. I'd encourage you to try it. Ive been writing lisp for 4 years and missed this idea exactly 0 times – Daniel Gratzer Oct 15 '13 at 13:58
  • @Alexey It isn't the same issue because they aren't the same thing. (:f x) and (f x) are doing the same thing calling a function on an argument. UAP at its most basic level. If you want to hide which method you are calling then that is a different matter. – stonemetal Oct 15 '13 at 16:58
15

First, a disclaimer: I'm not deeply familiar with the uniform access principle so you may want to take this with a grain of salt. That said, I would argue that Clojure does observe a uniform access principle: function calls.

The key quote on Wikipedia seems to be that "all services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation", and that's exactly the case with function calls in Clojure. In fact, everything in Clojure (and other Lisps) is a function call except for special forms and macros - and macros actually are functions, with the distinction that they operate on source code. You can even specify function call behavior for your own types by implementing clojure.lang.IFn:

(deftype Invokable []
  clojure.lang.IFn
  (invoke [this]
    :was-invoked))

(def invokable (Invokable.))
(invokable)                  ;=> :was-invoked

You may have in mind the use of keywords as functions, which are most specifically associated with hash-maps, but you can actually implement that behavior for different types as well. Here's a silly example where keyword access reads a file (with the same name as the keyword) from your home directory, or returns a default value if such a file doesn't exist:

(ns weird.example
  (:require [clojure.java.io :as io]))

(deftype WeirdKlass []
  clojure.lang.ILookup
  (valAt [this k not-found]
    (let [home (System/getProperty "user.home")
          file (io/file home (name k))]
     (if (.isFile file)
       (slurp file)
       not-found)))
  (valAt [this k]
    (.valAt this k nil)))

(def klass (WeirdKlass.))

;; assuming you have a file at $HOME/testfile
(:testfile klass)        ;=> "test content!"
(:blah klass)            ;=> nil
(:blah klass :not-found) ;=> :not-found

Update based on Alexey's comment

I think I have a better idea what you mean now but in practice I haven't found it to be an inconvenience. When you want or need a level of indirection/abstraction between your code's functionality and its underlying data representation the way to achieve it is: functions!

The simplest way would be to define full-name as a function which happens to use keyword lookup but could later be changed to instead compute the name (without clients knowing or caring):

;; For now
(defn full-name [person]
  (:full-name person))

;; Maybe later
(defn full-name [person]
  (str (:first-name person)
       " "
       (:last-name person)))

Of course, you could also use records and protocols:

(defprotocol IPerson
  (full-name [p])
  (first-name [p])
  (last-name [p]))

(defrecord Person1 [name]
  IPerson
  (full-name [_]
    name)
  (first-name [_]
    (first (.split name " ")))
  (last-name [_]
    (last (.split name " "))))

(def person1 (->Person1 "Joe Schmoe"))
(full-name person1)  ;=> "Joe Schmoe"
(first-name person1) ;=> "Joe"
(last-name person1)  ;=> "Schmoe"

(defrecord Person2 [f-name l-name]
  IPerson
  (full-name [_]
    (str f-name " " l-name))
  (first-name [_]
    f-name)
  (last-name [_]
    l-name))

(def person2 (->Person2 "Joe" "Schmoe"))
(full-name person2)  ;=> "Joe Schmoe"
(first-name person2) ;=> "Joe"
(last-name person2)  ;=> "Schmoe"

The big (very big, in my view) upside of using "plain" data structures when possible is that it means you and your users have Clojure's full range of map and sequence operations at your disposal. Alan Perlis expressed this idea well when he said that "it is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

  • To clarify what I meant saying UAP: assume in Ruby in class User I have an attribute name. So I access it like user_instance.name. But then I can replace the name attribute with a method that computes it using first_name and last_name. And I don't need to update the client code. In case of Clojure I would have to replace in client code (:name ...) with (user/name ...) e.g. to have the same effect. – Alexey Oct 15 '13 at 12:46
  • @Alexey, thanks for the clarification - I updated my answer. – jbm Oct 15 '13 at 16:36
7

In short: it's considered not valuable enough to bother introducing. Replace a representation and re-factor/modify dependent code when you need it.

From an interview:

Fogus: Following that idea—some people are surprised by the fact that Clojure does not engage in data-hiding encapsulation on its types. Why did you decide to forgo data-hiding?

Hickey [creator of Clojure]: Let’s be clear that Clojure strongly emphasizes programming to abstractions. At some point though, someone is going to need to have access to the data. And if you have a notion of “private”, you need corresponding notions of privilege and trust. And that adds a whole ton of complexity and little value, creates rigidity in a system, and often forces things to live in places they shouldn’t. This is in addition to the other losing that occurs when simple information is put into classes. To the extent the data is immutable, there is little harm that can come of providing access, other than that someone could come to depend upon something that might change. Well, okay, people do that all the time in real life, and when things change, they adapt. And if they are rational, they know when they make a decision based upon something that can change that they might in the future need to adapt. So, it’s a risk management decision, one I think programmers should be free to make.

If people don’t have the sensibilities to desire to program to abstractions and to be wary of marrying implementation details, then they are never going to be good programmers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.