Sobrecarga de operadores cairia bem.
Falou o C++ orphan…
Capitão, para com isso…
É mesmo… Java deveria ter sobrecarga de operadores! :-o
… e structs também!
[quote=bicarbonato]É mesmo… Java deveria ter sobrecarga de operadores! :-o
… e structs também![/quote]
Vi em um post a equipe do Java ser contra sobrecarga de operador por considerarem que ele atrapalha a clareza do código, já que 1+1 você não vai poder saber se é igual a 2 a menos que leia o programa inteiro.
Não vou entrar no mérito se é bom ou não, mas achei engraçado o argumento.
mas 1 é tipo primitivo… int 
Eu não vou precisar ler o código! 
O lance é que você pode fazer o seguinte.
String str1 = "Esta é uma ";
String str2 = “String concatenada”;
System.out.println(str1 + str2);
A classe String implementou o operador + para concatenação.
Mas se você quiser implementar esse operador na sua classe, você não pode.
Por exemplo, eu tenho um portfolio de ações A, um portfolio B e um C, todos da classe Portfolio que criei.
Se eu quiser somar a e b e subtrair as ações de c no portfolio D, tenho que fazer assim.
Portfolio d = a.add(b.sub©)); (Pode ficar pior!)
Se suportasse a sobrecarga, ficaria simples assim:
Portfolio d = a + b - c;
Sobrecarga bem usada deixa o código MUITO mais legível.
I rest my case.
pra mim foram os caras não terem dado valor em coisas pequenas e simples do dia-a-dia, como o apache commons… resultado: 10 entre 10 frameworks tem essa dependencia
1 curtida
Sobrecarga de operadores torna o código confuso? O que te parece mais confuso?
Vector v1 = ((v2 + v3) * v1) - (4 * v4);Vector v1 = v1.multiply(v2.add(v3)) - (v4.multiply(4));Note que no segundo caso, fui obrigado a inverter a ordem da apresentação de algumas operações, como as multiplicações. No primeiro, seria possível buscar uma ordem que fosse matematicamente mais clara para a resolução do problema.
Sem falar, que se você quiser suportar operadores como +=, -= em classes matemáticas, você acabará com 2 assinaturas de métodos:
v1 = v1 + v2; v1 += v2;
v1 = v1.add(v2); v1.addMe(v2);
Por mim, o Java também teria que rever seriamente a organização do Swing, especialmente tirando fora o legado da AWT (que foi uma das grandes falhas do Java). Seria legal também retirar a classe DefaultTableModel, já que só serve para programadores preguiçosos fazerem programas confusos.
Implementação do generics sem reification e com erasure também foi um erro, na minha opinão.
Sem falar na API de datas, já citada.
A classe Enumeration era usada antes das Collections serem implementadas, e continua lá apenas por compatibilidade com programas antigos do Java. Qualquer novo software deve usar o Iterator.
[quote=thingol]Generics sem reification* foi uma péssima idéia. O próprio gerente da implantação do Generics no Java 5.0, o Neal Gafter, gostaria de ter incluído a reification, mas isso iria quebrar a JVM (que não iria ser substancialmente modificada no Java 5.0).
- Por exemplo: poder declarar List e tal declaração usar internamente um array de int mesmo. [/quote]
Reificação é uma boa, mas do ponto de vista do desenvolvedor não muda nada. O fato disso “incomodar” tanta gente tem mais a ver com fatores psicológicos do que algum ganho real de produtividade.
Ter as exceções bem documentadas é ruim? Como? Por quê?
Java ainda permite que você use RuntimeExceptions, portanto o que você advoga é não ter opção ao invés de poder usar checked e non-checked exceptions? Que o desenvolvedor ganha com menos opções?
Trabalhar com pointer? Mas que isso acrescenta no desenvolvimento de software? Nada, absolutamente nada.
[quote=eduveks]Ou seja… doGet e doPost além de não fazer sentido, sujam o código, um tapinha na orelha do cara q inventou isto!
Acho q só em Java q inventaram este conceito de GET e POST separados, como se fosse coisas independentes…[/quote]
Meu Deus do céu, quanta bobagem! Você tem problemas com opções para desenvolvedor? E se não for desejável receber request em GET e apenas em POST? Precisaria fazer if/else?
Cara, quer criticar critique, mas pelo menos diga algo que faça sentido.
[quote=victorwss]Que tal o maior anti-pattern em java de todos os tempos? A convenção de nomenclatura JavaBeans?
Se o método tiver um nome que inicia com get<letra maiúsula> ele se torna um método mágico! set<letra maiúsula> também o deixa mágico!
O negócio é entupir suas classes de getters e setters públicos![/quote]
Convenções de código existem em qualquer linguagem.
Na verdade, também não gosto das checked exceptions. Muitas vezes elas te obrigam a colocar try…catchs em pontos onde o sistema não pode fazer nada. Torna o código centenas de vezes mais confuso, só para você poder lançar novamente uma exception runtime, ou gerar um log. Veja o caso da SQLException. Não é à toa que APIs como o Spring, a eliminaram completamente.
A primeira vez que li o artigo contra as checked exception no Artima, não concordei. Mas aí passei a prestar atenção, e perceber que elas realmente trazem mais mal do que bem.
Checked exceptions também passam a fazer parte da assinatura do método. E isso prejudica a escalabilidade de uma API. Note que uma vez publicada, você não tem mais a opção de fazer com um método lance uma nova CheckedException, sem quebra-lo. E omitir uma checked exception existente (pq o método não a lança mais), fará com que seus usuários recebam centenas de warnings.
O desenvolvedor tem opção ao criar exceptions, mas não ao usa-las.
Concordo.
A questão está sempre em quanto tempo manter retro-compatibilidade. Fazer um programa Java 5 suportar uma compilação Java 1, só pela compatibilidade é uma boa? E porque não separar essas classes num pacote “oldstuff.jar” e deixar isso de fora das versões novas do JDK?
Ganha-se produtividade quando numa aplicação de performance mais crítica, pode-se usar lists no lugar de vetores primitivos. Boxing e unboxing tem seu preço.
Na verdade, também não gosto das checked exceptions. Muitas vezes elas te obrigam a colocar try…catchs em pontos onde o sistema não pode fazer nada. Torna o código centenas de vezes mais confuso, só para você poder lançar novamente uma exception runtime, ou gerar um log. Veja o caso da SQLException. Não é à toa que APIs como o Spring, a eliminaram completamente.[/quote]
Não precisa usar try/catch, basta adicionar um throws no método para quem quer que use aquilo se vire para cuidar do erro. E ainda isso é automático em IDEs como o Eclipse e Netbeans, ou seja, nem o trabalho de digitar isso você tem.
[quote=ViniGodoy]
A primeira vez que li o artigo contra as checked exception no Artima, não concordei. Mas aí passei a prestar atenção, e perceber que elas realmente trazem mais mal do que bem. [/quote]
Existem runtime exceptions para isso. Se houvesse apenas checked exceptions eu concordaria, mas é dada a opção ao desenvolvedor de usá-las ou não.
Pelo visto você não entende absolutamente nada de desenvolvimento em camadas. Simplesmente repassar um “throws sem trabalho algum” fere o encapsulamento das camadas. Pense bem, faria sentido você ter um método de camada de negócio que dispare um SQLException? E se esse método tiver um mecanismo de persistência injetado, para salvar, por exemplo, em arquivo e bd, ele disparará IOException e SQLException? Obviamente não.
Pior do que isso, o sistema não tem como se recuperar de nenhuma dessas duas exceptions, e o programador está tendo que se incomodar com elas.
Claro, vc ainda poderia manter essa filosofia, e fazer um throws Exceptions em absolutamente todos os métodos, para cedo ou tarde, cair num método de log. Mas aí, para que checked exception? Isso é equivalente a desligar completamente o mecanismo.
O C# não tem checked exceptions. E para ser bem sincero, não só não estou sentindo nenhuma falta, como estou agradecendo por isso.
Leu a entrevista?
Um dos maiores erros do Java pra mim não tem nada a ver com a linguagem, mas sim com o compilador.
Quando Java foi lançado, o compilador deveria ter a opção de gerar um executável (exe). Parece bobaem não é mesmo?
O problema é que vi MUITA gente desistir do Java simplesmente por não saber executar uma aplicação feita na plataforma.
Se tivessem feito isto no início, acredito que a história do Java no desktop seria outra (ignorando os problemas de perfomance que realmente existiam no início mas que hoje não existem mais).
Uma coisa bem esquisita: os métodos defaultWriteObject() e defaultReadObject() não fazerem parte de nenhuma interface.
Simplesmente implementar na classe torcendo para a assinatura estar certa não parece Java… tem mais a ver com aquelas funções de callback da API do windows.
Eu acho que estes métodos deveriam estar em uma interface CustomSerializable ou algo do tipo.
Não fere nada. De qualquer forma quando um erro ocorre uma exceção será lançada, seja ela checked ou não. A única diferença é que com checked exceptions você sabe o que esperar. E se realmente há a necessidade da camada de negócio dar um tratamento especial para o erro, então aí está mais uma razão para o try/catch e o tratamento correto do que ocorre.
Em ambos os casos, quando não há o que fazer e quando há o que fazer, os checked exceptions não atrapalham em nada.
[quote=ViniGodoy]
Pior do que isso, o sistema não tem como se recuperar de nenhuma dessas duas exceptions, e o programador está tendo que se incomodar com elas. [/quote]
Se o desenvolvedor não sabe programar as interfaces adequadamente , a culpa é dele e não da linguagem. Checked exceptions não muda nada isso, apenas garante que o erro seja tratado.
[quote=ViniGodoy]
Claro, vc ainda poderia manter essa filosofia, e fazer um throws Exceptions em absolutamente todos os métodos, para cedo ou tarde, cair num método de log. Mas aí, para que checked exception? Isso é equivalente a desligar completamente o mecanismo.[/quote]
Mas se tem gente que deseja retirar essa feature da linguagem… é melhor ignorá-la, e usá-la quando for necessário do que simplesmente retirá-la por uma questão puramente psicológica.
[quote=ViniGodoy]
O C# não tem checked exceptions. E para ser bem sincero, não só não estou sentindo nenhuma falta, como estou agradecendo por isso.[/quote]
Quais são as vantagens? Não tratar erros? Interessante, deixe o seu aplicativo falhar horrivelmente.
[quote=ViniGodoy]
Leu a entrevista?[/quote]
Sim, e assim como o pessoal daqui, é fraquíssima.