Kiss The Blade wrote:
>
> "Lisias A. Toledo" wrote:
> >
> > Nope. Vc tem os encapsulamentos dos primitivos em objetos. Que podem ou
> > n�o ser usados, � crit�rio do programador.
>
> De forma alguma. Os primitivos em Java s�o embutidos na sintaxe e n�o
[...]
> sei como funciona o modelo de Jython (www.jython.org), mas aposto minha
> m�o direita q � assim.
N�o, Thiago... Eu n�o sei onde vc andou aprendendo Java, mas ela era
claramente tendenciosa, omissa ou incompleta.
Existem objetos que descendem de java.lang.Object, e que foram feitos
para encapsular num modelo de objetos os tipos primitivos, de forma que
eles possam ser armazenados como objetos e passados por refer�ncia
quando necess�rio.
Observe o trecho de c�digo abaixo:
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());
Vc pode argumentar que a sintaxe � uma bela meleca, e eu vou concordar
com vc. Mas a coisa existe, e o simples fato do compilador n�o facilitar
as coisas pra vc (pois o compilador C# com certeza transforma o seu
c�digo de objetos num�ricos em algo assim) n�o significa que Java n�o
tenha este recurso.
Na hora do trabalho sujo, n�meros e caracteres s�o tipos primitivos para
efeitos de performance. Mas nada impede que vc armazene estes n�meros em
objetos encapsuladores, que est�o sim definidas no padr�o Java
(plataforma).
Em PVT segue um exemplo de c�digo (Teste1.java), que compila e executa.
> Em C#, todos os elementos mais b�sicos s�o derivados de System.Object, q
[...]
> sem no m�nimo uma classe... :)
Falou, falou, falou... E e descreveu com poucas diferen�as o que eu
disse acima. 8-)
> Granted, a C# tem ponteiros logo tamb�m n�o pode ser totalmente
> orientada a objeto. Mas enquanto vc pode escrever codigo 100% OO com C#,
> em Java n�o d� para fazer isso a partir do momento em q declara uma
> vari�vel. � s� uma quest�o de ver o que � de mais valor: deixar de ser
> OO pelo que tem ou pelo que n�o tem.
Aqui vc troca 6 por 1/2 d�zia. De um lado diz que tipos primitivos s�o
ruins, porque quebram o modelo OO. De outro, diz que em Java n�o d� pra
fazer um c�digo 100% OO por conta da falta de classes num�ricas, que eu
j� provei que existe.
Ok, a sintaxe para realizar opera��es com elas � uma meleca. Mas a coisa
t� l�. E eu n�o vejo como pecado declarar um inteiro para implementar um
contador, ao passo que ponteiros num ambiente de classes � absolutamente
uma aberra��o...
Java foi concebida para ser eficiente em c�lculos num�ricos.
Interessante que Smalltalk tenha sido preterida tanto tempo pela sua
falta de efici�ncia num�rica, e agora a C# esteja pregando justamente
isto...
> Wow, o Alexandre Oliva (acho q assina essa lista tb) escreveu uma
> arquitetura reflexiva no topo do Kaffe (www.kaffe.org) chamada Guaran�.
> Est� em http://www.dcc.unicamp.br/~oliva/guarana/. D� uma sacada, deve
> ter algo q vc aproveite.
Eu conhe�o, mas � muita areia pro meu caminh�ozinho... Mais tarde
talvez... 8-P
> Tudo embaixo de java.lang pode ser acessado transparentemente mas nao
> quer dizer que n�o tenha que ser instanciado, pois os construtores
[...]
> *facilidade* da linguagem mas nao quer dizer q o object model dela mudou
> por causa disso.
N�o, Thiago. Os m�todos est�ticos de uma classe ** n�o precisam ** de
uma inst�ncia para serem acessados.
Quando o compilador reconhece o uso de uma classe, ele insere c�digo
para que ela seja carregada em mem�ria. Mas n�o instancia nada. As
instancia��es s�o feitas, em geral, pelo operador new. E vc n�o precisa
instanciar uma classe caso o m�todo desejado tenha sido declarado como
static.
Um efeito colateral disto � que m�todos est�ticos s� podem acessar dados
est�ticos. Enviei um exemplo como Teste2.
Uma vari�vel est�tica numa classe Java torna esta vari�vel "global" para
todas as inst�ncias desta classe. Parece rid�culo algu�m pensar nisso,
mas �s vezes isto quebra uns galhos federais.
> Cara ent�o vc nao usa o mesmo Java q eu conhe�o ;). N�o existe objeto
> encapsulador de primitivos pq eles sao materlados na linguagem e nao
> precisam ser definidos em nada. Fechando essa discussao: o modelo comum
> de Java incluindo estruturas de dados simples � OO mas o sistema de
> tipos � PROCEDURAL.
J� provei que vc est� errado. Melhor trocar sua fonte de informa��es.
8-P
[...]
> *aus�ncia* de defines e por associacao, de um preprocessador. �s vezes
> um preprocessador faz muita falta. S� a t�tulo de compara��o: Java n�o
> tem preprocessador, e onde f*de � qd vc precisa declarar constantes,[...]
Use Interfaces e o modificador final. Veja em Teste3.java, esta eu
aprendi outro dia.
> > Porque Java s� faz switch com tipos primitivos. Em Java, strings s�o
> > objetos (mas isto � transparente via a��car sint�tico).
>
> Outra coisa interessante � que o tipo String � um objeto mas ele
> *tamb�m* � um vetor de char, um tipo primitivo. Olha a incoer�ncia :)
Mas vetores s�o tbm objetos, logo a incoer�ncia fica maior ainda. Exceto
pelo fato de que n�o h� incoer�ncia. Todo tipo primitivo em java possui
um equivalente em objeto, descendente de java.lang.Object como manda o
figurino.
Logo, um vetor de caracteres � um objeto cujo conte�do s�o inst�ncias de
uma classe chamada java.lang.Char, cuja fun��o � guardar um tipo
primitivo char num objeto. Pelo menos, na teoria. Na pr�tica, eu n�o me
surpreenderia se eles tivessem codificado o vetor de caracteres de forma
especial para aumentar a efici�ncia. Quase todo programa acaba lidando
com Strings.
Um exemplo de como isto funciona � estudar como Java trata Strings. O
que vc escreve n�o tem absolutamente nada � ver com o c�digo que o
compilador gera.
> > Todo objeto em Java � passado por refer�ncia.
>
> Claro, n�o podia ser de outra maneira. Mas primitivos n�o s�o. Vc ter� q
> declarar o primitivo, e criar um objeto para os primitivos,
> instanci�-los e s� ent�o pass�-lo para o m�todo. N�o � mais f�cil fazer
> direto?
Se d�vida. Mas isto que vc descreveu � somente a��car sint�tico. Um
compilador esperto faria o servi�o de forma transparente, caso isto
fosse desejado.
Mas em mi�dos, esta situa��o tende a ser muito pouco usada, de forma que
o overhead de se criar certas vari�veis como objetos e outras como
primitivas n�o chega a ser um inc�modo fatal. Pelo menos eu nunca tive
problemas com isto.
> As delegates s�o um elemento novo e funcionam como se fossem 'ponteiros
[...]
Fui conferir. Mas tenho tend�ncia de confiar na experi�ncia da Borland
(que a Sun alega ter consultado), afinal, a Microsoft trocou seu modelo
de objetos pelo da Borland... 8-P
Ahh... Inner Classes funcionam no Java 1.1
> De fato, ponteiros s�o uma aberra��o. Mas tem gente q gosta, fazer o q
> :)
8-P
> Eu acho que uma linguagem OO tem q ser consistente no seu object model.
> Nenhuma das duas �, mas as inconsistencias de Java acabam fazendo com q
> vc tenha q escrever MAIS codigo e chamar MAIS objetos para fazer a mesma
> coisa q a C# com palavras chave normais.
Mas isto s� acontece quando vc n�o conhece direito os recursos que a
linguagem tem para oferecer.
Normalmente os empecilhos que vc mencionou podem ser solucionados de
outras maneiras, e nem por isto a solu��o final perde eleg�ncia. O uso
de interfaces para se criar defini��es "globais" de constantes � um
exemplo.
> Logo, linguagicamente :P
> acredito q a C# tem muitas vantagens em cima de seu concorrente
> justamente por causa desse trade-off.
Em mi�dos, vc gosta de a��car sint�tico!!! 8-) Vc vai regularmente ao
dentista???? hehehahahaha 8-)
> E sobre o SOAP... ainda bem que nem todo mundo pensa como vc, sen�o
> estar�amos escovando bits em hexa direto no cabo serial, ligado no
> codificador de sinal de fuma�a :)
De forma nenhuma!! Algum infeliz escovaria os bits e criaria uma
biblioteca padr�o. O resto do mundo usa a biblioteca padr�o.
Comunica��o entre processos por rede n�o � novidade. Procurando por
"data interchange" na RFC-Editor eu achei mais rfcs do que estou a fim
de ler (ok, a maioria j� t� obsoleta).
Eu n�o consigo acreditar que um programa criar um arquivo texto
semi-estruturado com dados ASCII de 7 bits (que foram convertidos de sua
forma bin�ria) para enviar por uma conex�o de rede (de 8 bits, logo 1/8
da largura de banda j� dan�ou s� a�) para outro programa, que por sua
vez vai parsear o arquivo para extrair os dados para ent�o convert�-los
de ASCII para bin�rio, para ent�o pode usar, seja uma id�ia de usar
eficientemente os recursos dispon�veis.
XML tem seu lugar ao sol, principalmente para armazenar dados
semi-estruturados de uma forma independente e padronizada. Mas como RPC,
acho que um m�todo mais eficiente deve ser usado.
--
[]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 04/12/2001: 2395
Mensagens recebidas desde 07/01/1999: 144669
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
