Elegante ?: Elegante ? elegante voce implementar uma coisa dessas e passar seu programa para frente... quando tiver um a++; o cara que debuga tem serios problemas até descobrir que o "erro" veio na funcao de sobrecarga...

Quanto mais complexa a linguagem... mais torna as coisas xunxaveis...

Acho que sobrecarga de operadores deveria ser um tema a ser discutido na ONU.... no conselho de seguranca... quem usar... leva bomba... hehehe

E os xiitas de plantao podem parar... estou falando NAO que nao seja uma coisa boa... e sim que contribui para "mistificação" de uma classe... para ilegibilidade da mesma...

E por favor... sem "gurus da informatica"... estamos falando de programadores de mercado... e eles estao bem longe de serem "os fodas"...

Sobrecarga elegante?: Sobrecarga de operadores é um recurso elegante? Desde quando?

Ele é sim, um recurso maravilhoso para usar se o que você quer é mascarar a intenção do que vc. está escrevendo. É ótimo para tornar seu código ilegível para todo mundo que não quiser gastar o tempo necessário para entender o que está acontecendo.

Não, não é um "recurso exclusivo para poucos" e usar algo assim não prova que vc. é "O f0d4". Se quiser ser espertão escreva seu programa em código de máquina, assim quem botar os olhos nele saberá que a intenção foi escrever algo ilegível, exceto para o "dono".

Qualquer idiota pode escrever um programa que uma máquina é capaz de entender. Os bons programadores escrevem códigos que os *seres humanos* são capazes de entender fácil e rapidamente.

Com essa onda de linguagens de script ultra-dinâmicas, parece que as pessoas estão perdendo a proporção entre escrever menos código e escrever o suficiente para possibilitar o entendimento do mesmo.

Um código "complexo" sem sobrecarga de operadores eu leio e entendo passando os olhos sobre ele. Um código "simples" com sobrecarga pode me fazer gastar até mais de 5 minutos procurando a &@%#$#@ do código de sobrecarga e descobrindo o que ele faz.

Senhores...: ...leiam o artigo antes de atacarem.

Primeiro, só para fazer notar, Python não possui um operador de incrementação "++". É bom estudar um pouco antes de falar, gente...

De qualquer forma, sobrecarga de operadores é bom e elegante, sim! Você pode até achar que é mais elegante escrever

complex1 = complex1.add(complex2)

mas a notação que eu aprendi no Ensino Médio é

complex1 = complex1 + complex2

e - por que não? - também não tenho nada contra

complex1 += complex2

(embora aceite que algumas pessoas não gostem).

Sobrecarga de operador é ótimo quando o objetivo é manter compatibilidade com uma notação universalmente conhecida - e é isto que o artigo faz, explicando como se implementar números racionais. Certamente é ruim para representar I/O, assim como uma função chamada "add" é ruim se seu objetivo é escrever na saída padrão. Alguém que use o operador "+" num lugar impróprio é o mesmo tipo de pessoa que usaria uma função "add" no lugar. Não é culpa da ferramenta.

É tudo questão de bom senso. Ao menos em Python operadores são usados com muito mais parcimônia e bom senso que em C++. Se você acha que não possui este bom senso, não use a técnica.

--
Adam Victor Nazareth Brandizzi
Site: http://brandizzi.googlepages.com
"Real programm

Brandizzi: Em primeiro lugar, não creio que tenha se tratado de um "ataque" a uma linguagem. As críticas foram direcionadas ao recurso de sobrecarga de operadores, não à linguagem Python.

Primeiro, só para fazer notar, Python não possui um operador de incrementação "++"

Que é um açúcar sintático interessante para se acrescentar a *linguagem* (e não a adicionar só ao programa tal escrito pelo programador qual). De qualquer forma, ninguém será realmente limitado devido a falta deste.

Sobrecarga de operador é ótimo quando o objetivo é manter compatibilidade com uma notação universalmente conhecida

Não creio. Mantendo compatibilidade com uma notação "universalmente conhecida", vc. quebra a compatibilidade com a especificação original da linguagem, que é no que os outros programadores se baseiam ao ler seu código.

Também acho interessante as propostas apresentadas para o operador de adição. Mas a definição do operador deveria valer para a linguagem e não ser passível de variação para cada aplicação.

Sobrecarga de operadores é um recurso com um altíssimo potencial de abuso. Mas esse pior caso nem é o mais importante. Vc. pode sobrescrever um operador para representar um conceito bastante lícito e extremamente claro para você, mas não necessariamente para o leitor.

Ele espera ler um código escrito em Python e em lugar disso encontra vários operadores fazendo coisas que ele não conhecia como parte da linguagem. Isso o fará perder o tempo necessário para compreender o que está acontecendo, mesmo que ele tenha uma boa suspeita (bons programadores nunca confiam que as coisas realmente sejam como parecem ser).

Duplicado: Duplicado

Elegante ou não....: ...sobrecarga de operador é importante e só confunde desenvolvedores que não tem noção sobre o código que estão "fuçando" (o que não é nada dificil de se encontrar nos dias atuais).
Um exemplo são linguagens como MatLab que tem sobrecarga para os operadores de igualdade, soma, subtração, multiplicação dentre outras, para realizar operações com matrizes !!!!

Se o caboclo, que está trabalhando com operação entre matrizes (bem natural no mundo dos jogos 3D), se confundir, por exemplo, com uma soma de duas matrizes da forma conforme descrita abaixo (escrita em linguagem abstrata):

Matrix A = {1,0,
1,1};
Matrix B = {2,1,
2,3};
Matrix Result;


Result = A + B;


Pode mandar prende-lo......

Ou seja, o problema é que tem muito "fuçador" na área e que não tem noção sobre conceitos matemáticos e muito menos computacionais.


--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

...sobrecarga de operador é: ...sobrecarga de operador é importante e só confunde desenvolvedores que não tem noção sobre o código que estão "fuçando" (o que não é nada dificil de se encontrar nos dias atuais).

A questão é que numa empresa, quase nunca sem tem acesso ao código original, exceto documentação de APIs.

E sim, eu acho mais claro matrixA.add(matrixB), do que ficar imaginando se a linguagem joga a matrixB na cauda ou se ela soma os elementos.

O Nemesis tá fazendo falta ...: ... com seus comentários ácidos (porém bem embasados - corretos ou não :)

Pois é...: ...Onde será que o cara foi parar?

Eu por exemplo já tive arranca-rabos lendários com o cara por aqui, por coisas como estas...

"...sobrecarga de operador:

"...sobrecarga de operador é importante e só confunde desenvolvedores que não tem noção sobre o código que estão fuçando"

Ao contrário, os que não conhecem a linguagem em questão pode até ser os menos prejudicados!

Quem conhece a linguagem, sabe o que esperar e bate com a cara no muro. A coisa fica ainda pior quando se trata de uma linguagem com tipagem dinâmica ou fraca. Na linha:

. . .
C = A + B
. . .

Levando-se em conta que lendo o trecho não dê para saber que A e B são matrizes, isso pode deixar qualquer um maluco.

Depois de descobrir que se trata de matrizes, a dúvida ainda continua: se trata de uma soma de matrizes (no Mathlab, provavelmente seria o caso, mas dá pra confiar?), uma concatenação de matrizes, ou alguma outra coisa qualquer??

Alguém que não conheça a linguagem pode até chutar certo neste caso, mas quem conhece pode se confundir.

Pode mandar prende-lo......

Correndo o risco de efetuar uma prisão com variados graus de injustiça. Principalmente porque, segundo a lei de Murphy, o @¨#%$@%!&! do operador de adição poderia muito ter sido sobrescrito para somar as duas matrizes, calcular a determinante do resultado e guardar o valor no banco de dados...

O método add() também poderia? Sim, poderia. Mas ao menos é um pouco mais fácil de enxergar a capivarada...

Foi o que eu falei.....: Result = A + B

Conceitualmente, não é o mesmo que "jogar a matriz B na cauda da matriz A" e sim somar duas matrizes.

O problema é mais embaixo.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Enxergando a capivarada ......: ..... com um método add() ???

Nada que um "Step into" resolva tanto pra um quanto pra outro.

Quanto ao problema das linguagens com tipagem fraca........isso é um outro problema grave......mas apenas da linguagem que possui esse tipo de abordagem !!

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Já, já ....: ...ele aparece....ainda mais que o tema tipagem fraca entrou na jogada !

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

"Nada que um "Step into":

"Nada que um "Step into" resolva tanto pra um quanto pra outro."

Hã? Vc. está me dizendo para depurar a aplicação? Só pra entender um código???

:-O

No caso do método add() ele é fácil de achar, pois ele te leva diretamente à implementação do método em caso de dúvida (e vc. estará muito mais acostumado a verificar a implementação de um método que a procurar sobrecargas de operadores que vc. não sabe se existem), a sintaxe é clara e direta.

"mas apenas da linguagem que possui esse tipo de abordagem !!"

Python, a linguagem abordada no artigo, por exemplo?

Depende...:

"Conceitualmente, não é o mesmo que "jogar a matriz B na cauda da matriz A" e sim somar duas matrizes."

Isso na sua cabeça. O problema com sobrecarga de operadores é que isso varia da cabeça de quem redefiniu o operador...

Imagina em uma linguagem nativamente compilada e alguém acrescenta código que redefine um operador em código legado, digamos um simples *, compila e vai pra casa.

Show de horrores na produção... Hehe.

Tudo bem, nessa eu apelei... :P

Python: "Python tem uma maneira fácil de fazer sobrecarga de operadores"

Não é só Python. Todas as linguagens que conheço que suportam sobrecarga de operadores, fazem da mesma maneira: vc sobreescreve métodos específicos. Por que então em Python é diferente das outras linguagens neste sentido?

Sobre linguagens "tipadas fracamente". Que eu saiba, tanto Python, Ruby quanto PHP possuem tipos como outras linguagens, mas as variáveis sim é que são dinamicamente tipadas.

Java nao tem sobrecarga de: Java nao tem sobrecarga de operadores :)

Tipagem Fraca:

"Sobre linguagens "tipadas fracamente". Que eu saiba, tanto Python, Ruby quanto PHP possuem tipos como outras linguagens, mas as variáveis sim é que são dinamicamente tipadas."

Até onde conheço, dizemos "tipagem fraca" quando a declaração de tipo para uma variável é opcional. Todas as linguagens de tipagem fraca que conheço possuem tipos, sim. Apenas não se requer que estes sejam declarados de forma explícita.

Já o recurso da "tipagem dinâmica" significa que o interpretador descobre qual o tipo adequado para a variável em tempo de execução e não de compilação.

Por exemplo, eu diria que o VB 5.0 (eca!) tem tipagem fraca mas não dinâmica, ao lembrar que, se vc. não declarar explicitamente uma variável o *compilador* considera a mesma como um tipo "variant".

Vc. está certo: Graças ao Bom Deus e Todos Os Santos, não tem mesmo! :-)))

Ou melhor, até tem um: o operador + muda de comportamento (de adição para concatenação), quando um dos termos é um objeto java.lang.String.

Mas Java não permite que o programador reescreva os operadores. E sou grato até hoje por isso.

Não estamos falando .....: ...de péssimos hábitos de programação estamos ???????

"Isso na sua cabeça. O problema com sobrecarga de operadores é que isso varia da cabeça de quem redefiniu o operador..."

Se o cara redefiniu para o operador fazer uma coisa completamente ilógica, porque não criar uma função add() para fazer o mesmo ???

Se o cara faz isso ele é um porco maldito e deve ser banido do mundo do desenvolvimento.

Sem contar que sobrecarga de operadores não funciona da forma como vc citou, tipo eu redefino o operador + para fazer subtração e pronto !!! Está funcionando para todo mundo...negativo !!! O compilador só faz a operação dependendo do relacionamento entre as classes que redefiniram o operador e até mesmo checando se é possível uma operação entre as mesmas, caso contrário um erro de compilação será gerado (claro para as linguagens de tipagem forte, nas de tipagem fraca um run-time error talvez), ou seja, está na hora de vc rever seus conceitos sobre sobrecarga de operadores.


--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Qual o problema do step into ......: ...se vc pode faze-lo olhando o fonte ?? Quando vc lê um programa ou sub-rotina não é um "step into" no olho ???

Ou vc não iria ler o método add() para saber do que se trata ???

Sobre a tipagem de Python...não conheço, mas o exemplo poderia ser de C++, Java, Delphi.......enfim.....muitas

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Eu avisei que tinha apelado: Quando eu falei de maus hábitos de programação, eu avisei que eu apelei, não reclama! :P

No entanto, quando eu disse:

"Isso na sua cabeça. O problema com sobrecarga de operadores é que isso varia da cabeça de quem redefiniu o operador..."

Não me referi a algo necessariamente ilógico. Pode ser compreensível, ainda que não seja da forma como eu ou você pensamos.

Se eu tenho dois conjuntos ordenados de inteiros, A e B:

Resultado = A + B

Isso, a primeira vista, poderia sugerir que se trata da operação cantoriana da soma dos conjuntos (união).

No entanto, se o programador tivesse sobrecarregado este operador para retornar um conjunto onde cada elemento fosse a soma algébrica de cada elemento dos operandos, seria justo vc. trancá-lo a ferros? Acho que não. Foi uma intenção lógica, apenas não tão clara quanto se poderia desejar.

Pelo fato de que métodos possuem um nome, por si sós já são mais expressivos do que operadores.

está na hora de vc rever seus conceitos sobre sobrecarga de operadores.

Cara, eu já disse que foi uma brincadeira... rs*

Mas linguagens de tipagem fraca (aquelas das quais estamos falando aliás) poderiam sim ter problemas em tempo de execução com isso.

Método X operador:

...se vc pode faze-lo olhando o fonte ?? Quando vc lê um programa ou sub-rotina não é um "step into" no olho ???

Quando vc. vê uma chamada de método, sabe que uma operação cujo teor vc. ainda não sabe está acontecendo ali. Seguir para a implementação dele é a seqüência natural.

Quando vc. vê um uso de operador, acha que já sabe o que acontece, ou seja, vc. está desarmado. A menos que considere muito estranho o uso do operador naquele contexto.

Mais uma vez, isso é muito mais difícil de notar em uma língua de tipagem fraca do que com tipos fortes.

o exemplo poderia ser de C++, Java, Delphi.......enfim.....muitas

Ei! Não leu acima? Java não permite sobrecarga de operadores definidas pelo programador.

Java e operator overload: Não tem, e eu deixei claro quando disse "nas linguagens que suportam sobrecarga de operadores". Por incrível que pareça, não foi Python ou Ruby que inventaram isso, e existe desde C++. No projeto da linguagem Java, operator overloading foram removidos por opção, assim como heranças múltiplas e as closures (que talvez agora entrem, vejam o blog do James Gosling, um dos pais da linguagem).

Vc. está certo, claro: Sim, foi só um comentário do Joselito que eu respondi, nada mais.

E sim, C++ foi uma das primeiras línguas a usar o recurso, junto a um bando de outros que eu odiava nela.

que talvez agora entrem, vejam o blog do James Gosling, um dos pais da linguagem

Na verdade, não deve entrar na Java não. Principalmente porque haveriam poucos benefícios nisso.

Para "features" como essa, existe a linguagem Groovy, onde o pessoal pretende colocar todo tipo de recurso que não casa com a filosofia da Java, mas que é desejável para alguns.

Ela é uma língua de script que roda na JVM, é fraca e dinamicamente tipada, suporta coleções como tipo primitivo e suporta operator overload também. Se parece bastante com línguas como Ruby, Python, Scheme, etc.

Eu não uso porque não gosto de linguagens de script dinamicamente tipadas para 99,5% das coisas.

Quando citei Java .....: ...me referi a linguagem de tipagem forte e não o fato de possuir sobrecarga de operador, pois Java não possui tal característica mesmo nem sei se um dia terá. Acredito que não.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

Quando vc. vê um uso de:

Quando vc. vê um uso de operador, acha que já sabe o que acontece, ou seja, vc. está desarmado. A menos que considere muito estranho o uso do operador naquele contexto.

Ah, então o problema é que os operadores são semânticos demais! Uma abominação dessas deveria ser crime! :p

PS: senhores, não paguem mico. O resultado da soma de matrizes é uma matriz cujo elemento na i-ésima linha e j-ésima coluna é a soma dos correspondentes das outras. Não é concatenação de matrizes - operação que sequer existe, e que vocês não definiram. Que constrangedor...

--
Adam Victor Nazareth Brandizzi
Site: http://brandizzi.googlepages.com
"Real programm

A sobrecarga de operadores: A sobrecarga de operadores foi adicionada no C++, por exemplo, para que a programação genérica (templates) pudesse operar também com os tipos básicos (char, short, int, etc); sem a necessidade se criar objetos wrapper para esses tipos (como Java o fez). Quando a classe é bem construída e para um propósito específico, com a std::string, IMHO sua utilização é bem direta e não causa problemas.

No entanto em linguagem que não necessitem de tal recurso, não vejo necessidade alguma da sobrecarga de operadores. Métodos são mais diretos e não perdem em nada em expressividade.

O grande problema no fim é saber definir quando e como utilizar esse recurso. Em um projeto criado e executado com cuidado, creio que dificilmente será um recurso sintático que dificultará sua abordagem. No fim será uma questão de gosto do programador...

Ei!!!! Blog do Gosling?: A propósito, onde vc. viu no blog do Gosling a promessa ou possibilidade de sobrecarga de operador (definida pelo programador) para a Java?

Tenho o blog do cara ("On The Java Road") no meu leitor RSS, visito uma vez por semana e nunca achei nenhum post dele lá sobre isso.

Em todos os pronunciamentos do cara a respeito que eu já li ele exercita diversas maneiras possíveis de dizer "não" (no, never, etc.) quando perguntam sobre essa questão.

Se ainda lembrar, passa a URL do post aí, pra gente poder comentar.

Ahn.... Documentação?: "Com essa onda de linguagens de script ultra-dinâmicas, parece que as pessoas estão perdendo a proporção entre escrever menos código e escrever o suficiente para possibilitar o entendimento do mesmo."

Vc eu não sei, mas eu prefiro DOCUMENTAR o código, com comentário, análise e anotações à parte, do que simplesmente achar que uma pessoa tem que entender a lógica do programa, ainda mais como existe mais de uma forma para resolver um problema.

Por quê programado metido nessa coisa toda de open source tem que ficar com essa palhaçada de "Eu não preciso da documentação"?

Claro... para impressionar programadoras! Esquecia-me. My bad!

Documentação, comentários e etc.: Eu gosto da filosofia do Martin Fowler e do resto da galera do Extreme Programming que defende idéias como:

a) A documentação é importante, quando é realmente necessária. Ela não substitui um código claro.

b) Código bem escrito expressa a intenção de seu autor. De tal forma que documenta a si mesmo na maior parte das ocasiões.

c) Uma forma fácil de determinar quando um método está grande demais é observar a quantidade de comentários dentro dele. Cada bloco comentado geralmente pode ser extraído para um novo método que será nomeado da forma adequada. Essa vem do meu livro de cabeceira.

Eu gosto de impressionar as programadoras com projetos bem feitos e códigos bem escritos, é suficiente... ;-P

Exatamente o que venho citando .....: .....posts acima !!!!

O problema é conceitual, pois houve até quem disse que A + B é "jogar a matriz B na cauda da matriz A" !!!

Mas quem sabe todos os conceitos de operação entre matrizes e sabe que os objetos que estão sendo operados são matrizes, já deveria ter o implicito no raciocício o conceito de soma de matrizes ao ver A + B.

O mesmo sendo válido para as demais operações possíveis a serem feitas com matrizes.

Até que enfim alguém que enxerga além do código impresso !!

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team

que b...q...ce.:

"Não é concatenação de matrizes - operação que sequer existe, e que vocês não definiram."

Responda rápido: uma matriz pode ser considerada um conjunto?

Uma matriz (normal ou esparsa) pode ser considerada um conjunto com uma ordem específica de elementos.

Ou pode ser considerada um conjunto ordenado de conjuntos ordenados.

Ou como um conjunto não-ordenado onde cada elemento conta com uma chave (de dois valores combinados), ou seja, um mapa ou bolsa.

Sendo que uma matriz pode ser lida e manipulada como um conjunto, está sujeita a qualquer das operações disponíveis para os mesmos: união, interseção, subtração, diferença simétrica, etc.

Outra possibilidade seria tratar a matriz como uma tabela e usar operações relacionais de união, produto cartesiano, etc.

Mas acredito que quando o colega citou "concatenação de matrizes" se referia simplesmente a colocar matrizes lado-a-lado, coisa que é comum de ser fazer quando manipulamos matrizes de pontos em uma imagem, ao trabalhar com filtros por exemplo.

"Real programm" ("programmer"?), desce um pouco do altar, não fica bem.

"Ah, então o problema é que os operadores são semânticos demais! Uma abominação dessas deveria ser crime! :p"

Operadores dão informações de menos. Não é um crime, mas atrapalha. E sarcasmo barato não muda o fato.

Desculpe: Desculpe, mas o que o blog fala é sobre o uso de closures em Java. O Gosling explica que tentou evitar colocar elas em Java, mas que de certa forma ele acha que isso vai acabar acontecendo.

Só que em Ruby: Só que no tão badalado Ruby, [1,2,3] + [4,5,6] = [1,2,3,4,5,6]. Aí vc sobreescreve pra deixar do seu modo (a soma dos elementos), mas se precisar realmente da concetanação, aí faz o q? Cria um método list.concat() pra concatenar e usa + para somar?

Ah... Tá.: Mas closures são muito legais. Existiam outros motivos pro Gosling (que é conservador) torcer o nariz para elas:

* Closures são uma espécie de métodos que podem ser passados como parâmetros. Acrescentam muito poder a línguas funcionais. Mas elas são por excelência isso mesmo: um recurso puramente funcional. Existe o receio de que os programadores se apóiem demais em closures em lugar de escrever bom código OO.

* Acho eu que é mais complicado implementar closures em uma linguagem do que parece. Desconfio que seja preciso mexer na forma como os stack frames dos métodos são gerenciados.

Mas sim, closures são uma grande promessa para o JSE 7.0 (Dolphin).

Se ruby faz isso, então....: ....o já famoso termo, "jogar a matriz B na cauda da matriz A" é factível de aceitação.

Sobre seu questionamento, aí foi uma escolha dos implementadores de ruby, definir a utilização do operador + dessa forma.

Mas como o operador na linguagem já funciona assim, é mais lógico criar uma função SomaMatriz() do que sobrecarregar o operador, até mesmo porque no caso específico dessa linguagem a sobrecarga deverá confundir mais do que ajudar.....


Viu como o uso de sobrecarga é uma questão de bom senso ???

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/Linux - My dream team