Kiss The Blade wrote:
> Wrappers para 'solucionar' inconsistencias n�o � solucao meu amigo, �
> uma gambiarra :).
Bom, eu n�o disse que era uma solu��o perfeita. At� porque na minha
opini�o o tradeoff que eu tenho ganhando efici�ncia nos c�lculos
num�ricos e l�gicos (e a maior parte dos meus programas � fortemente
baseada nisso, exce��o feita ao meu projeto atual, baseado em tratamento
de strings e busca por express�es regulares) compensa.
> Vc est� raciocinando da mesma forma que o rapaz que disse que
> bibliotecas sao 'evolucao' do C. Pelamordedeus.
Eu n�o tenho tanta certeza do que vc afirmou n�o...
> > 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!
E eu n�o disse que tinha, pow!!! At� porque esta convers�o quando �
feita em outras linguagens, o � pelo compilador!!! � uma quest�o
sint�tica, n�o sem�ntica!!! (Ao menos, superficialmente).
Veja aquele meu exemplozinho idiota:
static java.lang.Integer i, j, k;
i = new java.lang.Integer(10);
j = new java.lang.Integer(20);
k = new java.lang.Integer(i.intValue() + j.intValue());
Como � que eu poderia afirmar textualmente uma coisa e na maior
cara-dura mostrar um contra-exemplo deste quilate na cara de todo mundo?
Por favor, transcreva o trecho onde eu afirmei isto, para que eu possa
analis�-lo e nunca mais repetir o erro...
Eu acredito que tenha afirmado que exista uma rela��o �ntima entre
java.lang e o compilador (i.e., defini��o da linguagem), e dei como
exemplo o tratamento de Strings. Mas n�o consegui encontrar onde afirmei
que os Integers fazem parte deste tratamento...
> N�o for�a a repetir isso pq tenho certeza q agora tu entendeu.
O que eu n�o entendo � onde eu afirmei o contr�rio... 8-X
> 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.
Aqui provavelmente vc est� certo. Tem algun link para iluminar minha
teimosia?
> Camarada, olha a chance q eu te dei de nao por em publico o lusitanismo
> que vc fez:
Teimosia � meu segundo nome. Cara-dura, o primeiro. N�o tenho
absolutamente nenhum constrangimento em falar bobagem em p�blico (como o
�ltimo caso do .deb), apenas em *continuar* a falar bobagem, mesmo
quando claramente est� provado que � bobagem (vcs nunca mais v�o ouvir a
mesma bobagem duas vezes!!!... hummm... acho que h� exce��es, n�
Patola?).
> "A 'trava��o' de uma constante em Java � feita pelo proprio
[...]
> durante o runtime."
Putz... Aqui vou ser obrigado � dar a m�o � palmat�ria (plaft!!!).
Prometo reler tr�s vezes posts posteriores, e n�o mais apenas duas como
tenho feito... 8-P
> 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?
Yap. Porque embora vc tenha raz�o na refer�ncia da constante, na hora do
pega pra capar, se as classes num�ricas s�o de fato descendentes de
System.Object, elas precisam de inst�ncia e transmiss�o de mensagens na
hora de serem utilizadas. Do contr�rio, n�o seriam objetos de fato (vc
afirma que �).
Granted, vc pode argumentar que o compilador "traduz" tudo isto numa
forma mais eficiente, que isto ent�o n�o ocorre no runtime... Mas neste
caso, tais objetos "primitivos" **n�o poderiam ter descententes**, ou
seja, teriam que ser todos final (alguns em Java o s�o, por motivos de
performance e otimizac�o - aka gambiarra - no c�digo. java.lang.Strings,
se n�o me engano, � final). Da� eu n�o vejo motivos fortes o suficiente
para defender o uso de "primitivos" como objetos. Exceto como forma de
manter coer�ncia sint�tica.
Mas a� ent�o cair�amos de volta naquele meu papo de a��car sint�tico...
Ou n�o?
> 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 :)
Eu sei. Mas vc n�o deixou claro (digo, n�o escreveu com todas as letras,
era necess�rio inferir, no que eu falhei...) se vc falava de efici�ncia
ou de inexist�ncia.
Eu entendi erroneamente que vc falava da inexist�ncia do recurso. L�gico
que estranhei, da� me dei o trabalho de fazer um exemplo...
E o fato de classes com s�mbolos est�ticos n�o precisarem ser
instanciadas para oferecer acesso � estes s�mbolos est�ticos tbm est�
escrito em tudo quanto � tutorial, e mesmo assim vc afirmava o
contr�rio...
p.s.:
> P� L�sias, t� aprendendo com os spin-doctors daqui?
Hummm... Talves esteja fazendo uma p�s-gradua��o... ;-)
--
[]s,
Pink ------------------------------------
(Lisias Toledo) | ECHELON AT MY BALLS !! |
Manaus/Amazonas/Brasil | Will My Freedom Be Forever Denied? |
--------------------------------------------------------------------
/"\ CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X
/ \ Movimento Pr�-acentua��o:
/ \ Use "MIME, quoted-printable, ISO-8859-1" em seu e-mailer.
Assinantes em 05/12/2001: 2386
Mensagens recebidas desde 07/01/1999: 145002
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
