Quais são as vantagens de um método “combinado” Getter / Setter VS Individual?

Isso é o que eu chamo de método getter / setter "combinado" (do 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")

Esta é a mesma lógica com métodos separados (teóricos):

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

Minha pergunta:

Ao projetar uma biblioteca como o jQuery, por que você decidiu seguir a primeira rota e não a segunda? A segunda abordagem não é mais clara e fácil de entender de relance?

Puramente especulando aqui, mas eu estaria inclinado a acreditar que os desenvolvedores do jQuery que usaram muito do estilo funcional na estruturação do jQuery claramente têm uma tendência para o paradigma funcional.

Dado que, no paradigma funcional, existe uma forte cultura de redução da redundância, e pode-se argumentar que a segunda abordagem possui redundância desnecessária. A primeira abordagem pode não estar clara para alguém acostumado a todas as linguagens imperativas comuns, mas é indiscutível fazer mais com menos por ter apenas um método em vez de dois. Isso pode ser perigoso, mas é uma ferramenta comum no paradigma funcional e algo a que se acostuma rapidamente.

Pratique no paradigma funcional e rapidamente supera esse desejo de cerimônia e aprende a apreciar a capacidade de fazer mais com menos. Embora esta seja reconhecidamente uma escolha subjetiva com base na preferência, da mesma forma que muitas pessoas têm preferências em relação ao gerenciamento de espaços em branco. Dessa forma, não estou dizendo que uma maneira é melhor, e sim que elas são as coisas com as quais as pessoas se acostumam, e é provavelmente por isso que o jQuery tem a abordagem que faz.

É por isso que acredito que os desenvolvedores do jQuery fizeram isso e, em geral, é por que alguém pode adotar essa abordagem.

A forma

foo.text("This is a new value"); 

pode implicar uma série de coisas. Geralmente, ele sugere um fooobjeto, com um método chamado de textaceitação de uma string, que faz alguma coisa . Não há nenhuma implicação de que essa seja uma propriedade.

Em muitos idiomas, isso pode ser considerado uma forma abreviada de

var result = foo.text("This is a new value"); 

onde o resultado é descartado. Portanto, essa abordagem é ambígua demais para ser uma maneira eficaz de definir uma propriedade (do ponto de vista da legibilidade do código).

É um pouco especulativo, mas aqui está minha chance.

O jQuery adota totalmente a natureza funcional do javascript. É isso que o torna tão incrível, mas pode deixar muitos desenvolvedores coçando a cabeça quando eles vêm de uma linguagem OO mais pura, como o java. Parece quebrar todas as convenções e boas práticas.

O idioma funcional tende a enfatizar uma sintaxe declarativa. Tende a ler como uma declaração de fato, em vez de como comandos. Exemplo

var eligible = customers.where(c => c.age > 30);

que pode ser lido como "o cliente qualificado são os clientes com mais de 30 anos". Por constraste, a linguagem imperativa é lida como uma sequência de comando

for (customer in customers)
    if (customer.age > 30)
        eligible.add(customer)

Pode ser lido como "Verifique cada cliente e, se tiver mais de 30 anos, adicione-os à coleção qualificada"

Adicionar aa sete uma getoperação faria o jQuery parecer uma biblioteca imperativa. Você pode construir o caminho para ler as seguintes instruções

// 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();

Mantendo as ações verbais fora da API do jQuery, elas fizeram com que parecesse uma API declarativa. Dá uma sensação consistente e funcional à biblioteca. É por isso que acho que eles sobrecarregaram as palavras-chave.

Faz com que ele se comporte de maneira um pouco mais parecida com as propriedades , que foram introduzidas recentemente no JavaScript e, portanto, ainda não são amplamente utilizadas, especialmente em bibliotecas como o jQuery, que ajudam a abstrair as incompatibilidades do navegador.

Se você já olhou para uma definição de classe cheia dessas propriedades, os prefixos "set" e "get" parecem supérfluos, porque a adição do parâmetro value já indica que é um setter. Martin Fowler faz um bom argumento sobre getters que exigem um parâmetro, mas mesmo assim, nesse contexto, o parâmetro de valor adicional indica claramente um setter, bem como o fato de um setter raramente aparecer no lado direito de uma tarefa. E quando você está escrevendo um código, é necessário examinar a documentação da biblioteca de qualquer maneira.

Como você só pediu vantagens, não vou cobrir as desvantagens.