Tipologia <T> como fazer isntanceof T

Que o compilador some com o T, eu sei... so que da mesma forma que ele subistitui os T por Cidade e cria os métodos correspondentes...

ele poderia subistituir

candidate instanceof T

por

candidate instanceof Cidade

é tão simples substituir isso quando subistituir no resto, não entendo a dificuldade real de fazer isso... mais enfim... paciencia...

e de toda forma... eu vi que realmente o erro de cast é dentro do filter... fiz o seguinte e comprovei...

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Lavieri wrote:candidate instanceof Cidade

é tão simples substituir isso quando subistituir no resto, não entendo a dificuldade real de fazer isso... mais enfim... paciencia...

É simples mas não tem lógica alguma. Raciocina...

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Que tal isso aqui:

public class FilterUtils_Sugestao {
	
	static class Cidade {
		public String getNome() {
			return "João Pessoa";
		}
	}

interface Filter<T> {
		public boolean match(T o);
		public Class<? extends T> targetClass(); // Implementações são obrigadas a dizer que tipo de coisa elas filtram 
	}

public static <T> Filter<Object> toGenericType(final Filter<T> filter) {

return new Filter<Object>() {
			public boolean match(Object candidate) {
				// A implementação me dirá a classe com a qual o filtro trabalha 
				return filter.targetClass().isInstance(candidate)? 
					filter.match((T) candidate) : false;
			}
			public Class<? extends Object> targetClass() { 
				return Object.class;
			}
		};
	}

public static void main(String[] args) {
		
		Filter<Cidade> cidadeFilter = new Filter<Cidade>() {
			public boolean match(Cidade candidate) {
				return candidate.getNome().equals("João Pessoa");
			}
			public Class<? extends Cidade> targetClass() {
				return Cidade.class; // Sou um filtro de Cidade
			}
		};
		
		Filter<Object> genericFilter = FilterUtils_Sugestao.toGenericType(cidadeFilter);
		System.out.println(genericFilter.match("teste")); 
		System.out.println(genericFilter.match(new Cidade()));	
	}

}

This message was edited 1 time. Last update was at 07/04/2009 19:13:10

eu acho triste, ter que informar a classe quando há tipologia...

hora, a tipologia devia vim para facilitar esse trabalho, ter q informar a classe em 2 lugares acho algo triste =/

mas talvez seja obrigado a fazer isso =/

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Eu acho triste você querer coisas sem sentido.

Realmente cara, dá uma lida sobre Generics, aí tu vai entender como instanceof T não tem lógica. Depois você pode até continuar insatisfeito, mas pelo motivo certo (não vou te dizer, vou deixar pra você concluir).

This message was edited 2 times. Last update was at 08/04/2009 11:57:11

Lavieri wrote:Que o compilador some com o T, eu sei... so que da mesma forma que ele subistitui os T por Cidade e cria os métodos correspondentes...

ele poderia subistituir

candidate instanceof T

por

candidate instanceof Cidade

é tão simples substituir isso quando subistituir no resto, não entendo a dificuldade real de fazer isso... mais enfim... paciencia...

Aí é que está o porém. O COMPILADOR NÃO FAZ ISSO. Ele substitui T por Object e ponto-final. Daí ele cria alguns casts e alguns métodos ocultos para lidar com a incompatibilidade.

Na verdade, a forma como generics foi implementado é uma gambiarra. E como toda boa gambiarra está cheia de problemas estranhos e regras obscuras. Eles implementaram assim para que não houvessem problemas de compatibilidade com java 1.4 e inferiores.

C++, por exemplo, faz essa substituição mais ou menos da mesma forma que você falou. Mas isso gera dois problemas:
1) Você tem centenas de classes sintéticas. Em C++, coisas como List<Cachorro>, List<Gato> e List<Integer> são diferentes. Além disso, trabalhar com coringas (aquele ?) seria muito mais complexo no java (C++ não tem coringas). No java, como o generic é apagado, você tem List simplesmente.
2) Problemas de compatibilidade com o java 1.4. Se o generic não fosse apagado do bytecode, seria necessário adicionar alguns atributos ocultos em diversas classes.

Além disso, há casos onde substituir não seria possível. Por exemplo:
Aqui, essa substituição não funcionaria. Na linha com o ***, ele deveria colocar o que? Integer? String? A única coisa que dá é Object mesmo. Se fosse substituir por Integer ou por String, teria que fazer isso para cada objeto, e isso iria requerer uma classe para cada tipo de objeto. Ainda assim ia ter alguns probleminhas quando uma superclasse tivesse um generic em um método final. Outra alternativa seria simplesmente mandar a compatibilidade com o java 1.4 e inferiores para o espaço, mas uma das bandeiras do java é justamente a retrocompatibilidade.

Eu acho triste você querer coisas sem sentido.

sem sentido??

eu vi sentido no que o Lavieri falou e concordo.

não entendi na falta de sentido ai.

uma justificativa pra que ele não faça isso pode ser:

Na verdade, a forma como generics foi implementado é uma gambiarra. E como toda boa gambiarra está cheia de problemas estranhos e regras obscuras. Eles implementaram assim para que não houvessem problemas de compatibilidade com java 1.4 e inferiores.

não um modelo da Linguagem Java.

Virtual Machine Man Membro desde: 04/08/2010 09:37:57 Mensagens: 543 Offline

pois é, também acho que faz todo sentido...

quando se começar a usar generics cedo ou tarde você acaba tendo necessidade (ou desejo) similar...

os artigos abaixo explicam bem os motivos que fizeram generics ser implementado assim:

http://www.ibm.com/developerworks/java/library/j-jtp01255.html
http://blog.caelum.com.br/2008/04/28/nao-posso-descobrir-nem-instanciar-tipos-genericos-porque/

e esse aqui uma forma NÃO recomendada de (talvez) contornar esse problema:
http://blog.caelum.com.br/2006/10/29/brincando-com-generics-o-bizarregenericdao/

apesar de entender os motivos dessa técnica de erasure eu realmente gostaria que generics tivesse mais poder...

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