Sobrecarga de Operadores

Mas tudo isso para trocar um "add" por um "+"?
Não acho legal não.

Tem sempre gente reclamando por ai que java suporta coisas demais, por isso da complexidade.

Tem tanta gente estusiasmada com o RoR exatamente pela simplicidade do mesmo, agora por que vamos encher o java de "jeringonças"(não sei como se escreve isso), simplesmente para dar "maaaais uma" possibilidade de dinamizar o código porém sem ganho nenhum?

AndrewAguiar wrote:...

Então, vocês querem obscurecer essas formas díspares de trabalho com operadores comuns. Recai no que eu comentei sobre os métodos add parônimos. Dentro de um sistema, que pode virar um monstro no curto ou longo prazo, deixar livre essa escolha pode ( e em geral vai ) se tornar prejudicial a interpretação. Numa parte do código, o "+" mescla dois produtos, em outra "+" agrupa emails de um cliente, em outra incrementa o contador de visitas, em outra sobrepõe o endereço de entrega etc.

Com a verbosidade levantada para deixar o código mais legível, frente as reclamações das linguagens que usam nomes obscuros( ou alguém logo de primeira, só de bater o olho, já sabe o que faz array_uintersect_uassoc ) , sobrecarregar símbolos para supostamente deixar mais legível, tende a ficar paradoxal.

Até!

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3201 Offline

AndrewAguiar wrote:Olá Pessoal.

Por que Java não tem sobrecarga de operadores.

A razão para isso é simplicidade e manutenção da linguagem.
Quando vc tem sobrecarga de operadores, na realidade vc pode implementar sublinguagens. Imagine que cada API de terceiros, por ai, criáva seus proprios operadores. Ia ser uma dor de cabeça...
Associação de operadores como é usado no Groovy parece mais interessante. Por exemplo, o sinal + pode ser usado por qq classe que implemente plus() e o sinal * por multiply() e variável["string"]=a por put("string",a) e assim vai. Agora definir novos simbolos (como se faz no C) parece meio caminho andado para complicar demais as coisas.

Acho que simplesmente permitir a sobrecarga do operador '+' no Java não iria mudar tanta coisa assim, como já foi falado, o método add() aparece atualmente em trocentas classes, dá no mesmo. A questão é que sobrecarga de operadores vai muito além do operador '+' (digo isso porque quase toda a discussão neste tópico ficou focada neste operador). Se a feature de sobrecarga de operadores fosse aprovada no Java num molde semelhante ao que temos em C++, poderiamos sobrecarregar praticamente qualquer operador. Isso inclui:
++
--
/
*
[]
==
!=
<
>

e por ai vai.

Perceberam o nível de complexidade disso? Se deixar, vira uma zona fácinho, fácinho.
Eu não quero ficar comendo documentação, quero escrever código. Do mesmo modo que utilizar add() é ambiguo, utilizar sobrecarga de operador também é. Dá na mesma procurar na documentação de todas as classes que implementam uma interface que possui o método add() ou nas subclasses de uma classe que sobrecarrega o operador '+'.
enfim, uma bagunça...
Por outro lado, para tentar acabar com ambiguidade no nome de métodos, temos que tornar o Java cada vez mais verboso, com nomes de métodos que definam exatamente o comportamento esperado, para todas as classes. Eu acho que já escrevo demais para programar em Java...
Sinceramente não vejo muita solução para isso não. Vai de estilo de programar. Java não tem sobrecarga, ponto final. Quer sobrecarga, vai programar em C++. Mas também não reclama que Java é verboso... Temos que conviver com isso.

JavaChild Membro desde: 18/07/2006 10:03:59 Mensagens: 124 Offline

nbluis wrote:Mas tudo isso para trocar um "add" por um "+"?
Não acho legal não.

Tem sempre gente reclamando por ai que java suporta coisas demais, por isso da complexidade.

Tem tanta gente estusiasmada com o RoR exatamente pela simplicidade do mesmo, agora por que vamos encher o java de "jeringonças"(não sei como se escreve isso), simplesmente para dar "maaaais uma" possibilidade de dinamizar o código porém sem ganho nenhum?

E por que fizeram o for-enhanced ?

Teoricamente tudo que voce faz no for-enhaced voce ja conseguia fazer antes com o for normal.

para dar agilidade.

E pelo que sei Ruby apesar da simplicidade tem sobrecarga de operadores.

também concordo que definir simbolos novos é meio suicida, mais poderia ser assim voce pode sobreescrever somente os operadores já existentes operadores...

Concordo sobre o for enhanced....
E não citei ruby quanto a ter ou não sobrecarga.

Meu exemplo foi apenas para citar que esse é mais um dos que um cara acostumado com outra linguagem mais vai olhar um código java e vai dizer "WTF".
Ao invés de agilidade, traríamos mais complexidade sem agregar em nada.

Qual a diferença na agilidade você consegue enxergar nessas duas representações?

Virtual Machine Man Membro desde: 13/01/2005 12:31:27 Mensagens: 718 Offline

AndrewAguiar wrote:

E por que fizeram o for-enhanced ?

Teoricamente tudo que voce faz no for-enhaced voce ja conseguia fazer antes com o for normal.

para dar agilidade.

Eu acho a diferença entre uma chamada de método e o uso de operador bem pequena, se comparada à entre for-enhanced e usar iterator (embora eles pudessem ter criado um "foreach").

Não consigo ver muita vantagem no uso de sobrecarga de operadores. Talvez se conhecesse melhor, veria.

nbluis wrote:Concordo sobre o for enhanced....

Eu não. O enhanced for é só uma maneira de não tornar aparente o uso do Iterator, não uma sobrecarga de lógica.
Quem quiser comparar, compile e rode depois com javap -verbose:

Coincidentemente, os dois loops em bytecode são muito parecidos. O mesmo não aconteceria se fosse trabalhado sobrecarga do operadores como no C++.

Continuo convicto que a verborragia é uma convenção muito boa. espalhar métodos parônimos por todo lado pode ser extremamente prejudicial.

Até!

JavaChild Membro desde: 18/07/2006 10:03:59 Mensagens: 124 Offline

nbluis wrote:Concordo sobre o for enhanced....
E não citei ruby quanto a ter ou não sobrecarga.

Meu exemplo foi apenas para citar que esse é mais um dos que um cara acostumado com outra linguagem mais vai olhar um código java e vai dizer "WTF".
Ao invés de agilidade, traríamos mais complexidade sem agregar em nada.

Qual a diferença na agilidade você consegue enxergar nessas duas representações?
public add(T a){ /*codigo*/ } public +(T a){ /*codigo*/ }

Exemplo:

Sem Operador:

Com operadores:

Bem mais simples e limpo

No caso os operadores resolvem da esquerda para a direita e a implementacao poderia ser.

AndrewAguiar wrote:...

Sem tentar forçar a barra:

Até!

JavaChild Membro desde: 18/07/2006 10:03:59 Mensagens: 124 Offline

maquiavelbona wrote:

AndrewAguiar wrote:...

Sem tentar forçar a barra:
StringBuilder b = new StringBuilder(); b.append("A").append("B").append("C").append("D").append("E").append("F") .append("G").append("E").append("H").append("I").append("J").append("L") .append("M").append("N"); System.out.println(b.toString());

Até!

Mais ai voce esta escrevendo 8 caracteres a mais para implementar:
b.append("A")

e o código fica bem mais dificil de entender.

no outro não, voce só de bater o olho ja sabe o que esta havendo.

Eh claro que também não adianta escrever pouco e depois se ferrar para entender o código, mais no caso com o operador fica até mais claro a intenção do código.

AndrewAguiar wrote:...

Vais ter que criar outro método para fazer o que o append já faz, além de ter que transformar o "+" em um método que já existe (será que não irá montá-lo como append em bytecode?).
Conheço bons programadores que reclamam do C++ por permitir isso, pois eles odeiam os antigos mantenedores do código que eles estão trabalhando agora.

Mas "+" o mais poderia significar add(), append(), put(), offer(), doSomethingThatIDontKnowWhatItDoes() e tantos outros métodos diferentes que eu acho que a vantagem que ele talvez desse em criação seria sobrepujado pela complicação em manutenção.

Até!

JavaChild Membro desde: 18/07/2006 10:03:59 Mensagens: 124 Offline

maquiavelbona wrote:
Vais ter que criar outro método para fazer o que o append já faz

Não só delegar para o original, assim se mudar a implementação os dois mudam, no caso de classes basicas eles simplesmente dariam os operadores como uma maneira mais simples de fazer o mesmo trabalho do metodo. Não tiraria a compatibilidade com nada antigo e ainda quando o programador quisesse mudar o metodo append por exemplo ele só mudaria ele, ja que o operador chama este..

maquiavelbona wrote:
Mas "+" o mais poderia significar add(), append(), put(), offer(), doSomethingThatIDontKnowWhatItDoes() e tantos outros métodos diferentes que eu acho que a vantagem que ele talvez desse em criação seria sobrepujado pela complicação em manutenção.

Que complicação haveria em dar manutencao nestes metodos ?

AndrewAguiar wrote:...

Podes me falar se o "+" é add(), offer(), publish(), merge(), concat(), kill() ou outro método só de bater o olho? O método é explicativo por si só?

Até!

Obs.: Mudei o nome da classe para não falar que minha classe nao diz nada.

AndrewAguiar wrote:...
Que complicação haveria em dar manutencao nestes metodos ?

Pense que você tem 200 classes que o "+", "-", "/" ">>" fazem coisas diferentes? Como saber qual será o comportamento sendo que ">>" pode simplesmente dar um System.out.println() ou pode fazer uma operação maluca? Isso em não garante legibilidade, garante que você pode se confundir com o tempo.

Até!

Notícias, artigos e o maior fórum brasileiro sobre Java