This is what I call a "combined" getter/setter method (from jQuery):

var foo = $("<div>This is my HTML</div>"),

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 = 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?

  • 6
    Martin Fowler isn't a fan of what he calls "overloaded getter setters": martinfowler.com/bliki/OverloadedGetterSetter.html Jan 11, 2013 at 16:10
  • 1
    I used to like the get/set split method (thinking it made the code more "obvious"), but I'm finding the overloaded getter/setter pattern more attractive these days. It can make the code cleaner. I've never found myself liking Mr. Fowler's compromise. It seems to me that it's the worst of both worlds. Jan 11, 2013 at 16:45
  • Martin Fowler's only real argument against it is when the 'getter' passes in an argument, in which case it's confusing to the reader in that it doesn't look like a getter. As of now, I've concluded that if you stick with the convention that the getter takes no arguments, and the setter takes one, that, along with clear API comments, the jQuery/Angular approach should be just fine. For now. Apr 24, 2014 at 15:28

4 Answers 4


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.

  • 2
    Agreed, plus I'd add the desire to reduce JS size as much as possible.
    – Matt S
    Jan 11, 2013 at 16:18
  • -1 for the imperative/verbose and functional/implicit points.
    – user39685
    Jan 11, 2013 at 16:24
  • 3
    @MattFenwick I don't mean to offend, are you saying it's untrue that the functional paradigm has a leaning towards implicitness where imperative paradigm has a leaning towards explicitness? I'm not saying either is better, just that one can get used to one or the other which would cause you to automatically do things in that way as opposed to the other (this goes for either way equally) Jan 11, 2013 at 16:45
  • @Jimmy no problem; my point was just that in my experience, I've found implicitness/explicitness to be orthogonal to FP/imperative.
    – user39685
    Jan 11, 2013 at 16:57
  • @MattFenwick could be, but I would say aside from the type inference which allows a lot of implicitness and is common to the HM type system, other things common to FP languages lean towards implicitness as well like all the operators-as-functions where the function doesn't have an explicit name, just a symbol you are expected to learn and know implicitly, or the common use of lists or tuples requiring implicit knowledge of member meaning and location instead of DUs (think about how the writer monad works). I also tend to see a commonality of single letter parameter names, but you may be right Jan 11, 2013 at 17:14

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

  • This is an excellent point! I put on my FP goggles when I read javascript and things look differently so I didn't even think about this, but if I saw code like this in C# I would have exactly the reaction your'e referring to "Wth does this method do??". Jan 11, 2013 at 17:23

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)

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>

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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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