Sobrecarga de Operadores

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

Olá Pessoal.

Por que Java não tem sobrecarga de operadores.

Andei aprendendo Python recentemente e me parece um recurso bem util, existe alguma questão de design que faz com que eles não implementem ?

O que voces acham, tipo

ou com mapas

com um StringBuilder

no caso substituindo os append.

ou então nas suas proprias classes

Enfim não daria mais produtividade ?

Falow a todos

Sobrecarga de operadores eh util pra um numero tao pequeno (porem extremamente frequente) de usos, que eu nao sei se vale a pena ser feature da linguagem.

Por outro lado, dah uma olhada no que o why_ fez no hpricot

Tem gente que acha que sim, tem gente que acha que não. Já foi discutido isso várias vezes.

Se quiser, vote aqui para ter operator overloading.

http://forum.java.sun.com/thread.jspa?threadID=624342&messageID=3550166

Até!

Seria muito bom para contornar o sofrível suporte a aritmética com datas do Java....

Pior que isso só regular expressions com o seu match tentando dar um match na string inteira e não apenas em qualquer parte dela...

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

O problema é: o que um código desses faz?

Soma os anos de fabricação, a capacidade dos tanques, a quilometragem rodada ou não tem nada a ver?
Flexibilidade e legibilidade andam em sentidos opostos. Não sei até que ponto isso vale a pena.

Schuenemann wrote:Soma os anos de fabricação, a capacidade dos tanques, a quilometragem rodada ou não tem nada a ver?

Chama o metodo public Carro +(Carro) da classe Carro, ueh. O que esse metodo faz depende da implementacao.

Sinceramente não concordo com o argumento de que overload de operadores podem deixar o código mais complicado ou afetaria a legibilidade. Tudo depende do programador, assim como ocorre com o nome de método. Eu poderia muito bem fazer um método chamado add() que multiplicasse ao invés de somar.
A possibilidade de operador sobrecarregado não seguir a semântica padrão não é maior que com os nomes dos métodos, mas em compensação se teria uma grande vantagem de simplificar a sintaxe em muitas construções.

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

cv wrote:

Schuenemann wrote:Soma os anos de fabricação, a capacidade dos tanques, a quilometragem rodada ou não tem nada a ver?

Chama o metodo public Carro +(Carro) da classe Carro, ueh. O que esse metodo faz depende da implementacao.

Mas é isso que considero o problema: você precisa ver a implementação pra saber o que ele faz.

André Breves wrote:Eu poderia muito bem fazer um método chamado add() que multiplicasse ao invés de somar.

Tá, aí você poderia escolher um nome ruim. Mas, no caso do operador, não há nome algum. (Meu exemplo é meio tosco, é verdade).

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

Schuenemann wrote:Mas é isso que considero o problema: você precisa ver a implementação pra saber o que ele faz.

Ou então ver o Javadoc, como em qualquer outro método.

No caso o operador seria uma mera abreviação do metodo, para dar mais legibilidade, mais nada impediria voce de documenta-lo.

E se eu tivesse 2 classes com o "+" sobrecarregado com comportamentos diferentes? E se tivesse 20? E 200? Iria ficar lendo o javadoc de todas para saber o que o "+" faz em cada uma?

O Java querendo adotar um padrão e vocês querendo fugir de um comportamento comum.

Até!

maquiavelbona wrote:E se eu tivesse 2 classes com o "+" sobrecarregado com comportamentos diferentes? E se tivesse 20? E 200? Iria ficar lendo o javadoc de todas para saber o que o "+" faz em cada uma?

exatamente a mesma coisa que tu tem que fazer com o metodo add de todas estas 20 ou 200 classes

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

maquiavelbona wrote:E se eu tivesse 2 classes com o "+" sobrecarregado com comportamentos diferentes? E se tivesse 20? E 200? Iria ficar lendo o javadoc de todas para saber o que o "+" faz em cada uma?

O Java querendo adotar um padrão e vocês querendo fugir de um comportamento comum.

Até!

Não entendi, no caso assim como num metodo o operador do objeto à esquerda ia ser aplicado.

Exemplo de uso:

Permitido pois c2 é um tipo de caixa:

Daria erro pois nem toda caixa é uma SuperCaixa

urubatan wrote:...

Colocar o nome dum método de add sendo que vai ter N métodos parônimos é deveras estúpido. Se você soma um carro com um carro, e um parafuso com um parafuso, os métodos, em tese, deveriam ser nomeados singularmente, pois os comportamentos são singulares. Senão, de nada adianta essa verborréia na convenção se você não faz uso dela. Se vais somar carros, supôe-se que seja algo do tipo addCar, se vai somar parafusos, addScrew ( ou suas variantes addAnotherScrew, addOneMoreScrew, addLotsOfScrews(List<Screw> listScrews)), assim por diante.

Até!

Obs.: Desculpem o estúpido, não achei palavra melhor. Não se sintam ofendidos com meu vocabulário diminuto.

Aliás, somar carro com carro, para mim, é coisa de recuperadora de veículos. Faz sentido somar produtos a uma cesta. Se ambos fossem sobrecarregados com "+", o comportamento do primeiro seria juntar dois carros, do segundo aglomerar produtos dentro de um cesta. Viu que complicação sendo que existe uma convenção de símbolos?

Até!

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

maquiavelbona wrote:Aliás, somar carro com carro, para mim, é coisa de recuperadora de veículos. Faz sentido somar produtos a uma cesta. Se ambos fossem sobrecarregados com "+", o comportamento do primeiro seria juntar dois carros, do segundo aglomerar produtos dentro de um cesta. Viu que complicação sendo que existe uma convenção de símbolos?

Até!

Mais isso de fazer sentido varia de acordo com a sua regra de negócios, não tem nada a ver com a linguagem.

Eu poderia ter um produto que ao ser somado com outro seria um produto composto.

tipo minha regra de negócios diria que posso comprar tanto um Saco de Arroz quanto juntar diversos produtos e virar um só