I'll add one more answer related to the comment:
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
First off, to be clear, Clojure does believe in encapsulation for hiding implementation details, and Clojure offers a lot of ways to encapsulate implementation details when needed, such as private vars or deftypes.
It does not believe in encapsulating information though.
Back to your example now, if you were to encapsulate this information behind a method inside a class you'd have:
class Person
+ getName
So at first our information was a single name. Now we've somehow managed to know the distinction of first and last, so we want to have firstName and lastName, you'll probably do this:
class Person
+ getName
+ getFirstName
+ getLastName
Now look at this a few time and tell me what's the point of these methods over just a map which would have started as:
{:name "string"}
And then becomes:
{:name "..."
:first-name "..."
:last-name "..."}
Clojure doesn't see any real benefit in wrapping information, information is passive, it is just data, so better to keep it as data.
Here's a bigger walkthrough. First we model a Person as a simple map with :name key.
(defn make-person
[name]
{:name name})
Now someone starts to depend on this information:
(defn say-hello
[person]
(println "Hello " (:name person)))
(-> (make-person "Johny Cash")
(say-hello))
Now we somehow change to collect people's first and last name separately, so we refactor, but don't want to break existing use of our information model:
(defn make-person
[first-name last-name]
{:name (str first-name " " last-name)
:first-name first-name
:last-name last-name}))
(-> (make-person "Johny" "Cash")
(say-hello)) ; It still works!
If we had encapsulated the information we'd have done either the same thing:
class Person {
Person(String firstName, String lastName) {
name = firstName + " " + lastName;
this.firstName = firstName;
this.lastName = lastName;
}
String getName() {
return this.name;
}
}
sayHello(Person person) {
System.out.println(person.getName());
}
Or we'd have done this:
class Person {
Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
String getName() {
return firstName + " " + lastName;
}
}
sayHello(Person person) {
System.out.println(person.getName());
}
Only that second refactor is not possible in Clojure, but as we said, information is passive, in that way there's no real benefit to that second way of refactoring over the first.
Clojure basically is saying that UAP provides no real benefit while adding a lot of additional verbosity and being less malleable because if your data is actually a computation or a complex object type with methods, it can no longer be easily serialized, introspected, enumerated, transformed, etc. What if you want to persist it to disk? Or store it in a database?
You also need to keep in mind this whole time that data is immutable in Clojure as well, and the functional style of programming strongly favors purity, so the idea that you can call person.name multiple times in a row and get a different name because it would be dynamically computed or queried from somewhere external that is mutable is a big no no for Clojure as well. And if all your fields are going to be immutable and referentially transparent, what's the point of computing them over and over or querying them over and over? Just gather/compute the data at creation of the structure and you're done, like I did in my example.
Finally, if for some reason you really need a way to do this, it is actually possible to do, there are libraries that provide something generally known as a lazy-map such as https://github.com/Malabarba/lazy-map-clojure or https://github.com/originrose/lazy-map. What these do is they let you define the value of a map as a function which will be realized only the first time the key for it is looked up and this provides a Unified Access as the lazy-map has the same interface as a normal map.
(:f x)and(f x)are different and access is not uniform. So your statement is not an argument.