Generics foram um erro?

This message was edited 3 times. Last update was at 28/06/2005 14:14:51

http://lambda-the-ultimate.org/node/view/804

Como o artigo cita, os cabelos comecaram a arrepiar quando eu vi a definicao da Enum no Java 5:

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Enum.html

article wrote:
So, I don't know how to ease into this gently. So I'll just spit it out.

Generics are a mistake.

This is not a problem based on technical disagreements. It's a fundamental language design problem.

Any feature added to any system has to pass a basic test: If it adds complexity, is the benefit worth the cost? The more obscure or minor the benefit, the less complexity its worth. Sometimes this is referred to with the name "complexity budget". A design should have a complexity budget to keep its overall complexity under control.

...

Which brings up the problem that I always cite for C++: I call it the "Nth order exception to the exception rule." It sounds like this: "You can do x, except in case y, unless y does z, in which case you can if ..."

Humans can't track this stuff. They are always losing which exception to what other exception applies (or doesn't) in any given case.

...

Without [an explicit complexity] budget, it feels like the JSR process ran far ahead, without a step back to ask â??Is this feature really necessaryâ??. It seemed to just be understood that it was necessary.

It was understood wrong.

Muito maneiro isso! É o que eu sempre defendo! Os caras que fizeram C++ assumiram que todos os programadores são super-dotados. Muita complexidade a troco de que ???? Java tá aí para provar que é a troco de nada!

Vejo que os designers de frameworks web não usaram esse tal Complexity Budget muito bem. Já os caras de EJB nunca ouviram falar sobre isso.

Voltando a parte de generics:

Eu acho complicado, e complica bastante a sintaxe da linguagem. Se isso tivesse saído na primeira versao de Java talvez nós estaríamos usando C++ aqui. Muita gente ia se assustar e fugir do Java.

A linguagem já está estabelecida e a galera da Sun resolveu arrojar. A questão que me importa é: "Se eu não quiser usar Generics, posso simplesmente ignorá-la?!" Isso é falso ou verdadeiro?

Espero que seja verdadeiro, pois até o momento continuo fazendo os meus casts feliz da vida.

A idéia de economizar casts é louca! Pra que isso ??? Quem erra isso ??? O cara tem que estar meio bêbado pra meter uma String dentro de uma List e depois tentar puxar um Integer. Isso só aconteceu comigo uma vez quando refatorei o meu código e mudei o objeto. Tirando essa ocasião eu nunca ganhei um ClassCastException no meu código.

Espero que o Generics não polua muito o JavaDocs e que eu possa viver sem ele durante um bom tempo ainda!

This message was edited 2 times. Last update was at 28/06/2005 13:38:26

Sérgio,

Generics não servem apenas para economizar Casts, mas para fazer a linguagem ficar mais type-safe. É como eu te dizer que fazer besteira num struts.xml é coisa de bêbado quando ouvir das configurações compiladas do mentawai

Retorno covariante também é algo bem interessante. A comunidade C++ só ha pouco vem realmente aplicando o potencial dos templates, mas tipos parametrizados são rpevistos desde o início da OOP.

Você pode ignorar templates no seu código, e provavelmente por mais algum tempo, mas em breve todas as biblitoecas portadas para Java 5 devem estar usando este recurso.

Eu gosto de Generics,

Ele serve inclusive como documentação veja o exemplo:

Acredito que o compilador acabe fazendo o Cast.

Uma das vantagens anunciadas seria que erros poderiam ser evitados durante a compilação.

Quando uso coleções sem generics, o Eclipse dá um warning, mas o quão grave é este warning, eu não sei .

O maior problema é em relação ao nome. Ao invéz de generics, deveria se chamar "especifics".

É uma humilde opinião ( ainda não li o link citado anteriormente )

Márcio

Genericity é um termo clássico de OOP

pcalcado wrote:
Generics não servem apenas para economizar Casts, mas para fazer a linguagem ficar mais type-safe.

Foi mal então !!!

Estou falando do alto da minha ignorância no assunto. Pelo jeito Genérics é algo mais profundo que eu ainda não captei, mas lá na documentação eles enfatizam pra caramba: Vc vai poder pegar erros de Cast no compile-time. Ohhhhhh!

pcalcado wrote:
Retorno covariante também é algo bem interessante.

Qual a diferença de Generics e Retorno covariante ???

Coisa boba de quem sempre teve medo de templates, e agora se assustou um pouco com generics (eu!):

No código acima, eu queria que, dado um Comparable no segundo método, um Integer fosse obtido do map, e, com autoboxing, o método change(int,Comparable) fosse chamado a partir da invocação feita em change(Comparable,Comparable).

Qual foi o resultado da execução? Loop infinito...por quê? Porque Integer implementa Comparable...

Eu assumo minha culpa por não ter estudado o suficiente os novos recursos da linguagem e ter confiado demais nesses recursos mesmo sem ter estudado, mas acho que esse tipo de erro custa a aparecer em projetos com prazo apertado e tal...[sigh]

generics possibilitam retorno covariante

não acho que os generics tenham sido um erro, acho que a maneira como foram implementados foi errada

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Estou usando e achando ótimo. Mas, realmente, que dá pra fazer coisas ininteligíveis com o treco dá. Basta usar com moderação \o/

pcalcado wrote:generics possibilitam retorno covariante

public <T extends ClasseQualquer> blabla(){ int a = fazAlgo(); return new T(a); }

Só pra ver se eu estou entendo Phillip:

Generics pode existir sem retorno Covariante ???

A idéia do Generics é o retorno Covariante, não? O que eu não estou captando ???

This message was edited 2 times. Last update was at 28/06/2005 14:27:13

Gente, para início de conversa, o JForum tá colocando um caracter > a mais. Por favor, olhem o link que o CV colocou para verem a exata declaração de Enum.

Generics não são complicados! Simplesmente as pessoas ainda não estão acostumadas.

Alguém acha isso complicado?

Certamente um iniciante em POO acha.

O fato de ser possível fazer coisas complexas com Generics não invalida sua iniciativa. Olhando as vantagens e desvantagens, acho que estamos ganhando.

Urubatan, qual seria então uma forma melhor de implementar os Generics?

Sim, Generics podem existir sem retorno covariante desde que não se permita mudar o tipo de retorno quando sobrescreve-se um método (como java<5 fazia).

Retorno covariante é uma das vantagens da aplicação de generics, descobrir em compilação erros que só seriam descobertos em runtime é outra... e por ai vai.

os generics da maneira como foram implementados não mantem a "genericidade" em runtime
isto quer dizer que eu não consigo ficar sabendo qual o tipo que foi passado e pior ainda, o seguinte fica ambiguo sem a informação do tipo generico em runtime (o exemplo era mais ou menos este, não lembro exatamente do link em que estava, mas passo o link pra ca assim que eu achar novamente)

o exemplo era mais ou menos este

This message was edited 2 times. Last update was at 28/06/2005 15:40:15

Olá

Se alguém se lembrar, eu já cansei de meter o pau nos generics. Para mim, que também nunca gostei dos templates do C++, foi complicação desnecessária.

A minha principal queixa sempre foi ver o desperdício de massa cinzenta em um negócio que não altera em nada os byte codes, não melhora a performance e cujos benefícios são relativamente pequenos. Minha bronca sempre foi perceber que algumas deficiências do Java continuavam sem atenção. Exemplos: o Java Print Service é uma colcha de retalhos, o javax.comm precisa de correções e revisão e o monolítico Java Web Start está longe de atender as necessidades de instalação/atualização em milhares de clientes.

Ainda gastaram mais um monte de massa cinzenta para reescrever todos os javadocs usando generics e para mim tudo ficou mais difícil de ler.

Ken Arnold wrote:The complexity of Java has been turbocharged to what seems to me relatively small benefit.

O Ken Arnold, que é um dos autores do primeiro livro que li de Java (*), apenas descobriu que o rei está nu.

(*) The Java Programming Language, Ken Arnold + James Gosling, 1996.

[]s
Luca

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