This is what I call a “combined” getter/setter method (from jQuery):
var foo = $("<div>This is my HTML</div>"),
myText;
myText = foo.text(); // myHTML now equals "This is my HTML" (Getter)
foo.text("This is a new value"); // The text now equals "This is a new value")
This is the same logic with separate (theoretical) methods:
var foo = $("<div>This is my HTML</div>"),
myText;
myText = foo.getText(); // myHTML now equals "This is my HTML" (Getter)
foo.setText("This is a new value"); // The text now equals "This is a new value")
My Question:
When designing a library like jQuery, why would you decide to go the first route and not the second? Isn’t the second approach clearer and easier to understand at a glance?
3
Purely speculating here, but I would be inclined to believe the jQuery developers who used a lot of the functional styling in structuring jQuery clearly have a leaning towards the functional paradigm.
Given that, in the functional paradigm there is a strong culture of reducing redundancy, and it could be argued that the second approach has unnecessary redundancy. The first approach may not be clear to someone used to all the common imperative languages, but it is unarguably doing more with less by having only one method instead of two. This may be dangerous, but it is a common tool in the functional paradigm and something one quickly gets used to.
Practice in the functional paradigm and you quickly get over that desire towards ceremony and learn to appreciate the ability to do more with less. Though this is recognizably a subjective choice based on preference in the same way many people have preferences regarding whitespace management. In this way I’m not saying one way is better, rather that they are things people get used to, which is likely why jQuery has the approach it does.
This would be why I believe the jQuery developers did this and is in the general why someone might take this approach.
8
The form
foo.text("This is a new value");
can imply a number of things. Most commonly, it suggests a foo object, with a method called text accepting a string, that does something. There’s no implication that this is a property at all.
In many languages, this can be consider an abbreviated form of
var result = foo.text("This is a new value");
where the result is discarded. So this approach is just too ambiguous to be an effective way to set a property (from a code readability point of view).
1
It’s a bit speculative, but here is my shot at it.
jQuery embrace fully the functional nature of javascript. That is what make it so awesome, but it can leave a lot of developer scratching their head when they come from of more purely OO language such as java. It seem to break all convention and good practice.
Functional langage tend to put the emphasis on a declarative syntax. It tend to read like statement of a fact rather than like commands. Example
var eligible = customers.where(c => c.age > 30);
which can be read as “the eligible customer are the customers whose age are over 30”. By constrast, the imperative language read like a sequence of command
for (customer in customers)
if (customer.age > 30)
eligible.add(customer)
That can be read as “Check each customer, and if their age is over 30, add them to the eligible collection”
Adding a a set and a get operation would make jQuery feel like an imperative library. You can constrast the way to read the following statements
// The element tag have an html of <p>hello</p>
$("#element").html("<p>hello</p>");
// content represent the html of the element tag
var content = $("#element").html();
//Imperative style
// Set the element tag to an inner html of <p>hello</p>
$("#element").setHtml("<p>hello</p>");
//Get the html of #element, and put it in the content variable
var content = $("#element").getHtml();
By keeping actions verb out of the jQuery api, they made it feel like a declarative API. It give a consistent, functional feel to the library. That is why I think they overloaded the keywords.
It makes it behave somewhat more like properties, which were only recently introduced to JavaScript, and therefore aren’t widely used yet, especially in libraries like jQuery that are meant to help abstract away browser incompatibilities.
If you have ever looked at a class definition full of such properties, the “set” and “get” prefixes look superfluous, because the addition of the value parameter already tells you it’s a setter. Martin Fowler makes a good point about getters that require a parameter, but even then, within that context the additional value parameter clearly denotes a setter, as well as the fact that a setter rarely appears on the right hand side of an assignment. And when you’re writing code, you have to look at the documentation for the library anyway.
Since you only asked for advantages, I won’t cover the disadvantages.