Eu aprendi a gostar de Ruby, apesar dos sublinhados, mas há algumas coisas na linguagem que realmente são deploráveis. Uma delas é a sobrecarga de operadores: você pode sobrecarregar “qualquer” operador, exceto =, .., ..., !, not, ||, &&, and, or, ::. Agora, eu me pergunto, qual a utilidade de sobrecarregar operadores se você não pode fazer isso para vários dos mais importantes? Melhor nem ter implementado a idéia.
(A falta de) sobrecarga de operadores em Ruby
February 24th, 2007 § 13
Não gosto de Ruby cara. Já fiz um sisteminha ou dois por imposição de clientes, ter que abrir mão de um tanto de coisas de linguagens mais robustas (como isso ai em cima) só pela facilidade do Rails num dá… prefiro um BOM framework em PHP, a velocidade e “facilidades” são praticamente as mesmas
alias, não que eu queira dizer que PHP é uma linguagem robusta!
“Melhor nem ter implementado a idéia.”
Vixi, hoje é um daqueles seus dias, hein? Vai dar uma voltinha na praça para ver se acalma as idéias.
Aqueles operadores que podem ser sobrecarregados são alguns métodos que não iriam complicar demais por causa da sintaxe. Eu já prefiro do jeito que está, com esses que estão aí, do que não ter nada, já é meio caminho andado.
Vai que mais para frente eles liberam os outros também e você fica feliz.
Sai para jantar e estava pensando … “coisas deploráveis”. Forçou a barra, hein?
Realmente você está em um daqueles seus dias. Talvez você tenha que dormir/descansar mais um pouco.
Fábio, o que eu não gosto do Ruby é mais sintático. Semanticamente, eu acho que está anos-luz de distância da maioria do que eu uso diariamente. O que eu estava tentando fazer, na verdade, era algo que geralmente virtualmente nenhum programador vai precisar por toda sua vida de programação. Mas, como respondi em outro comentário, fico irritado com implementações parciais.
Falando em PHP, estou usando o Cake e gostei. O PHP, programado corretamente, pode ser tão eficiente quando o Rails, eu concordo.
—
TaQ, era um daqueles dias.
Agora, falando sério, eu realmente fiquei incomodado. Se tem uma coisa que me tira do sério com qualquer linguagem, é uma implementação parcial de um conceito. Eu acredito que a coisa deve ser implementada com um todo ou deixada de lado. E na sobrecarga de operadores, o Ruby pisou na bola porque você fica querendo implementar algo mais sofisticado e a linguagem barra.
Sobre o segundo comentário, okay, okay, já dormi. Deploráveis foi forçar a barra mesmo. Comparado com as outras linguagens que eu uso no dia a dia, a falta de sobrecarga de operadores no Ruby é o menor dos meus problemas.
Mala.
O problema é que em Ruby alguns operadores são operadores mesmo, como o de
atribuição (=) ou os de criação de literais Range (.. e …), e outros, como +,
-, *, etc, são chamadas de métodos disfarçadas de operadores. Por isso é muito
mais fácil (eu diria até que é trivial) implementar a possibilidade de
sobrecarga desses últimos.
O problema com sobrecarregar os operadores de verdade é que isso possibilita
alteração na semântica da linguagem, o que pode gerar muitos problemas.
Permitir a sobrecarga da atribuição, por exemplo, numa linguagem onde tudo são
referências seria _muito_ perigoso .. .
TaQ, pô, dá um desconto. Eu estava me recuperando das quase 40 horas sem dormir.
—
Terceiro, como sempre fui um interessado em linguagens e compiladores, eu até entendo as razões por trás de decisões como essas, onde a complexidade da implementação afeta a disponibilidade de certas características sintáticas. Fazer o “design” de uma linguagem sempre implica em trade-offs de vários tipos.
Agora, eu acho que se a idéia de fazer algo estava lá, ela tem que ser implementada consistentemente. Implementar metade de sobrecarga é algo que frustra programadores. É perigoso? Claro! Mas o programador é, em última instância responsável pelo que faz com a linguagem. Ou você aprende a usar uma arma de fogo, ou não usa. Sempre vão existir os malucos que estouram os bagos por acidente, mas, fazer o quê?
“estouram os bagos por acidente”
Tou rindo até agora…
Eu concordo, se o programador fizer cagada, problema dele, não da linguagem. Melhor do que não ter uma funcionalidade (por ser “perigosa”) e obrigar os programadores a fazer um tremendo POG pra conseguirem o que querem.
Taí AOP, que é um POGão pra evitar classes abertas + um simples “alias” (vou ser queimado vivo por causa desse comentário…)
Bom… tb não importa a linguagem, sempre vai ter gente “estourando os bagos” nela. Até com aspirador de pó (http://darwinawards.com/stupid/stupid2000-05.html) a cambada consegue…
Se certos elementos ouvirem esse comentário seu, vão querer queimar você vivo mesmo, e aí você vai se arrepender de ter aparecido na Info Exame e ter mostrado sua cara para o mundo–principalmente porque você tem razão.
Quanto a “estourar os bagos”, ainda bem que existe seleção natural…
= voce overraida sim.
!, not, ||, &&, and, or, :: nao sao metodos, por isso nao da para sobrecarregar. Acho a implementacao bastante solida e funcional… voce tem algum argumento que defenda o ‘melhor nem implementar’?
afinal, nos ja temos C.. nao sei pra q inventar outras linguagens de programacao…
O = eu tirei da página seguinte: http://www.rubycentral.com/faq/rubyfaqall.html. Confesso que ele eu não testei, embora os outros tenha testado. O argumento é que eu estava em um dia ruim.
Mas, falando sério, qualquer implementação pela metade é frustante. A linguagem fica inconsistente e isso aumenta a barreira de aprendizado. Claro que isso é uma mera opinião e eu não presumo discutir porque o Matz fez assim. Provavelmente ele tinha uma razão muito lógica e válida que, se não diminui minha frustação, pelo menos explica. 
o problema é que NAO EH uma implementacao pela metade, Ronaldson. = é um metodo (voce pode escrever a=1 ou a=(1) ), enquanto && é um operador logico. Creio que nenhuma linguagem aceite override de &&, and e similares, corrija-me se estiver errado…
Existem dezenas de linguagens que aceitam override de operadores lógicos entre as quais C++, C#, Delphi, Smalltalk (no qual Ruby foi baseado), Lisp, etc, etc. Em Smalltalk, tecnicamente não existem operadores já que todos são mensagens, mas o ponto é válido até porque Ruby é (parcialmente) inspirado em Smalltalk.
O override de = é possivelmente o mais perigoso (tanto é que C++ possui vários itens semânticos em cima do mesmo) e é permitido. Permitir && e || seria bem parecido.
A não existência desse override impossibilita uma série de construções interessantes. Tudo bem que qualquer programador pode dar tiros no pé, mas com um uso sábio, a força declarativa da linguagem fica enorme.
PS. O nome é Ronaldo, mas não se preocupe: Rolando é mais comum do que Ronaldson em termos de engano.
