"Lisias A. Toledo" wrote: > > Nem eu afirmei o contr�rio. Apenas afirmei que existem as wrappers, e > que elas s�o usadas para solucionar as "inconsist�ncias" na pr�pria > linguagem.
Wrappers para 'solucionar' inconsistencias n�o � solucao meu amigo, � uma gambiarra :). Podem wrapear um elefante e jogar dentro da biblioteca padrao que a JVM vai tratar exatamente como ele � e nao muda em NADA a linguagem. Empacotem um BOEING na biblioteca padr�o, ele continuar� sendo um boeing para a JVM. Vc est� raciocinando da mesma forma que o rapaz que disse que bibliotecas sao 'evolucao' do C. Pelamordedeus. > Note que existe uma rela��o bastante �ntima (vc talvez prefira a palavra > "prom�scua") entre java.lang.* e o compilador, ou seja, entre a > biblioteca de objetos e a defini��o da pr�pria linguagem, que n�o possui > Strings como tipo "primitivo" (e sim implementada em biblioteca), mas > possui sintaxe definida para lidar > com eles. Releia o q vc escreveu e presta atencao: vc est� repetindo de novo aquela aberracao crente que est� certo, NAO EXISTE CONVERSAO ENTRE PRIMITIVOS E OBJETOS EM JAVA.LANG.TIPO durante a compilacao pq a *$@%^& dos primitivos sao explicitados na linguagem como tipos procedurais e martelados na implementacao da JVM! Vc est� querendo dizer que um int == java.lang.Integer para o compilador e q isso eh convertido na geracao do codigo objeto e isso NAO EH VERDADE. Eu j� te apontei a especificacao da VM, a especificacao da linguagem, um livro conhecido de Java, o que o cara que CRIOU a linguagem disse e vc ainda t� nessa. J� s�o quatro mensagens repetindo isso e d� a impress�o que est� tentando convencer a lista por lavagem cerebral. P� L�sias, t� aprendendo com os spin-doctors daqui? N�o for�a a repetir isso pq tenho certeza q agora tu entendeu. > E a� ca�mos naquele meu coment�rio sobre o SmallTalk... Tanto se > massacrou esta linguagem por falta de efici�ncia em computa��es simples > e rotineiras, e agora me vem a Microsoft e afirma que isto � bom! (...) > Chamada de fun��o (que se n�o for final ou static, ainda pode ser > virtual!!) para se fazer uma soma � meio brabo, n�? A transposicao dos objetos em tipos 'reais' da maquina (em tamanho em bits, etc) est� definido na implementa��o de baixo n�vel do framework e n�o martelado na linguagem. S� isso. N�o existe segunda/terceira/en�sima chamada de metodo para fazer uma soma pq a partir do momento em q a sua primeira classe � executada as definicoes de tipos sao carregados junto com o construtor padr�o. J� falei isso desde as primeiras mensagens e parece q vc nao entendeu. > Se vc pensou assim, perdeu. S� metade da mensagem falava sobre isto. (...) > P�, Thiago, deu o maior trabalho fazer os exemplos, vai dizer que nem > mesmo abriu o arquivo zip? Camarada, olha a chance q eu te dei de nao por em publico o lusitanismo que vc fez: vc declarou uma interface para emular um define, ou seja, definiu uma 'heran�a' q vai ter q ser implementada para estender o escopo da constante em todo lugar q fa�a referencia � mesma, e q vai ter o seu valor analisado no seu proprio arquivo .class separado TODAS as vezes em q for usada. Ou seja, fez a mesma coisa q eu disse h� DUAS mensagens atr�s: "A 'trava��o' de uma constante em Java � feita pelo proprio compilador, q tem q pecorrer todo o codigo q refere-se a ele em busca de algo q mude essa constante. Em C# constantes sao tratadas pelo preprocessador, logo 'const tipo variavel = valor' ser� executado bem mais r�pido que 'static final tipo variavel = valor' pois em C# o preprocessador substituir� 'variavel' por 'valor' em todo o codigo sem precisar ficar subindo pra l� e pra c� checando o valor da variavel durante o runtime." E tu ainda abre a boca pra falar de performance da C# onde uma definicao de constante vai ser simplesmente substituida por seu valor pelo preprocessador? O que vc me passou � b�sico da linguagem que se encontra em qualquer tutorial. Eu j� sei programar em Java, nao preciso q vc me ensine :) -- thiago pimentel | mad scientist | [EMAIL PROTECTED] Assinantes em 05/12/2001: 2384 Mensagens recebidas desde 07/01/1999: 144981 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
