Generics foram um erro?

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. :lol:

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!

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:

Map<String,Funcionario> pessoal = new HashMap<String,Funcionario>();

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

Foi mal então !!! :oops: 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!

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!):

HashMap<Comparable,Integer> keys;

void change(int i, Comparable c) {
  ...
}

void change(Comparable c1,Comparable c2) {
  change(keys.get(c1),c2);
}

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] :roll:

generics possibilitam retorno covariante

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

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

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:

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 ??? :roll:

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?

public class A {
   public static class B extends A {
      
  }
}

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)

public class C{ private void algummetodo(Set<String> s){ } private void algummetodo(Set<Integer> s){ } public static void main(String[] args){ Method m = C.class.getMethod("algummetodo",Class.forName("Set<String>")); } }

o exemplo era mais ou menos este

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.

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

Eu e provavelmente a grande maioria dos programadores Java ainda possuem um monte de questões que não foram respondidas pela galera que manja e defende Generics:

As minhas dúvidas principais são:

1. Qual é o valor prático de Generics, a não ser para pegar erro de cast no compile-time e para economizar casts por parte do programador? Falar que é para tornar a linguagem mais type-safe não ajuda! Qual é a vantagem de tornar o Java uma linguagem mais type-safe? Não tava bom do jeito que estava? O que tava ruim? Tem que colocar uma enquete do tipo: Quem aqui se incomodava de dar um cast nos objetos retornados de uma collection?

2. Pra que serve generics a não ser para fazer retorno covariante? (Vide pergunta anterior para entender porque eu não entendo o benefício prático de retorno covariante.)

Concordo plenamente, principalmente em relacao ao JWS que possui um classloader bizarro! Não consigo colocar o Lohis para rodar com ele. (Tentei durante dois dias!)

Que bom que não sou o único…

Mas sobre o Generics, eu ainda só usei pra estudo já que os servidores que eu uso deve demorar um pouco pra atualizar pro Java5… mas pelo pouco que eu usei a única vantagem que vi é de ser typesafe nas coleções. E ainda hoje me confundo com a sintaxe…

[]'s

Rodrigo

Não tenho certeza, mas acho que a Sun quis simplificar, para ficar mais parecido com C#. A M$ sempre diz que faz o mesmo com menos comandos ( linhas ) e talvez isto também tenha inspirado o aparecimento de Generics.

Mas quem não gosta, não precisa usar. Eu uso.

Márcio

marcioa1:

Não tenho certeza, mas acho que a Sun quis simplificar, para ficar mais parecido com C#. A M$ sempre diz que faz o mesmo com menos comandos ( linhas ) e talvez isto também tenha inspirado o aparecimento de Generics.

Mas quem não gosta, não precisa usar. Eu uso.

Márcio

Essa história que quem não gosta não precisa usar é meio fraca. Você pode não usar no código que você cria, mas é obrigado a conhecer quando vai fazer manutenção… Ou seja, já que existe não pode-se simplesmente ignorar a sua existência. :roll:

O mesmo vale para o do/while e tantas outras redundâncias existentes.

Sempre que se cria mais uma forma mais simples de se fazer alguma coisa, aumentam-se as possibilidades. Logo, o profissional aumenta o volume de coisas a se estudar.

Bom, a sun não vai tirar. Então acostumemonos.

Se alguém pudesse responder as minhas perguntas seria legal.

Pelo menos não vou mais encher o saco aqui quando surgir outro post sobre isso.

:lol: :lol: :lol:

Nenhum, só serve pra o que você já disse, do mesmo jeito que o Phillip já disse. Eu acho interessante, mas não acho que seja uma feature que vai mudar a vida das pessoas.

O que eu acho é que alguém deveria matar as classes internas anônimas e criar delegates em Java. E sem sobrecarga de operadores, por favor, já tive dores de cabeça suficientes lendo documentação de C# pra descrobrir se o cara implementou a p#@$@ do método ou não.

Generics e retornos covariantes são features independentes, um pode existir normalmente sem o outro.

Agora generics é uma coisa esquisita, melhorar a “segurança” dos tipos é uma coisa ótima para novatos, mas novatos não vao entender generics e os mais velhos normalmente não vão querer muito se preocupar com esse tipo de coisa…

Nenhum, só serve pra o que você já disse, do mesmo jeito que o Phillip já disse. Eu acho interessante, mas não acho que seja uma feature que vai mudar a vida das pessoas.

Epa, opa, pera la. Generics tornam muito mais explicito o que vc quer fazer com as colecoes. Isso eh um baita ponto positivo. Um exemplo: vejam o trecho de codigo abaixo e me digam se vcs sabem o que vai ter no HashMap mais pra frente:

Map fuinhas = new HashMap();

Agora, com generics:

Map<String, Mamifero> fuinhas = new HashMap<String,Mamifero>();

O codigo ficou maiorzinho, mas agora vc nao tem que ir atras do codigo que faz put() ou get() pra entender o que ta acontecendo ali. A melhoria de legibilidade eh bem significativa, talvez mais significativa que a economia dos casts (que, eu concordo, nao eh lah grande coisa).

Se vc tiver uma sugestao de como fazer isso sem quebrar a compatibilidade do codigo que ja existe hoje (e isso inclui o codigo da propria JDK), mantendo uma performance aceitavel, e sem inventar uma sintaxe bizarra, fique a vontade pra explicar direitinho, que eu mando pro pessoal aqui da ThoughtWorks que tah no JCP o mais rapido possivel

E, sobre a sobrecarga de operadores, so digo que vc precisa passar um tempo programando em Ruby

Generic são uma boa evolução, mas o fato de ter erasure coloca Java no mesmo saco que C++, de linguagens fracamente tipadas, e isso é uma pena.

No final das contas é impossivel usar bytecode compilado com generics nas jvms antigas, isso matou metade da justificativa para ter erasure.

O problema de tipos paramétricos, sejam templates ou generics, é que eles passam a carregar muito mais informação, e isso é um inferno para linguagens com declaração explicita de tipos. Ainda bem que eles usaram um sistema de tipos simples, senão teriamos tipos com 200-300 caractéres facilmente.

Moral da história, Java possui um sistema de tipos muito fraco, e foi preciso usar de violência para acomodar generics. Não acho ruim, mas nunca pretendo passar de mero usuário (acho que nunca vou precisar criar tipos genéricos). Espero que parem por ai, uma linguagem com semântica mais rica, com coisas como inferência de tipos, nâo vai prestar se for um patch pro Java.