"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 herdam de nada, enquanto todos os outros objetos herdam de java.lang.Object. Isso � uma incoer�ncia no design de Java (linguagem _e_ plataforma), pois os primitivos tem que ser inseridos no contexto do modelo objeto antes de serem usados em qualquer classe que opere com objetos, como as APIs Reflection e Collections. Isso � ruim pq como n�o existe modelo de tipagem comum na JVM cada um usa o seu, e todas as linguagens portadas para ela terao que usar a sua propria implementacao de tipos ao inves de herdar de uma, exemplo ficticio, java.Object diretamente, e isso compromete na hora em q vc precise integrar codigo em uma linguagem com codigo da outra na mesma JVM, pois ter� q criar uma segunda camada de abstracao de tipos comprometendo a performance. N�o sei como funciona o modelo de Jython (www.jython.org), mas aposto minha m�o direita q � assim. Em C#, todos os elementos mais b�sicos s�o derivados de System.Object, q por sua vez deriva da implementacao comum de baixo nivel do framework. E n�o, isso n�o implica que qualquer sominha precisar� instanciar mais uma classe para pelo menos 2 objetos, pois eles s�o tipos derivados do construtor padr�o de onde s�o herdados todos os objetos base, logo a instanciacao s� ocorre a partir do momento em que � declarada a primeira classe do programa. E *s�* nesse momento. E n�o d� pra fazer um programa sem no m�nimo uma classe... :) 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. > de dados, logo estou estudando Java e reflex�o at� as entranhas (n�o que > esteja entendendo muita coisa... heheehahahah). 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 n�o entendo patavinas de C#, mas conhe�o Java muito bem. Objetos que > possuem m�todos est�ticos n�o precisam de instancia��o para serem > acessados, ao contr�rio do que vc afirma. Tudo embaixo de java.lang pode ser acessado transparentemente mas nao quer dizer que n�o tenha que ser instanciado, pois os construtores basicos da linguagem, como arrays, s�o herdados de java.lang.Object e os conversores de tipo est�o em java.lang.[TIPO], ou seja, um n�vel acima. Quando o c�digo for executado, ele ter� q subir um nivel acima e executar os metodos correspondentes a cada objeto de td q nao estiver definido na java.lang.Object. Acesso transparente � classe padrao � uma *facilidade* da linguagem mas nao quer dizer q o object model dela mudou por causa disso. > Os m�todos de convers�o dos objetos encapsuladores de primitivos s�o (ao > menos, todos os que usei at� agora), est�ticos. Logo, eles gastam > mem�ria para a aloca��o do c�digo, mas n�o gastam mem�ria de dados nem > geram overhead de instancia��o quando usados. 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. > Compila��o condicional num ambiente de carregamento transparente de > objetos � uma aberra��o. Fa�a uma classe para cada situa��o e em > runtime, simplesmente use a classe apropriada. Nao � nem a questao da compilacao condicional, at� pq nao faz muito sentido compilacao condicional num ambiente onde a linkagem eh dinamica durante o runtime e d� pra plugar o q quiser pra consertar, mas a *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, pois em Java o escopo de uma vari�vel � a sua classe, ao inv�s de um objeto. 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. Veja q sao aplicacoes diferentes: os projetistas de C# tiveram em mente q a linguagem iria ser usada para gerar executaveis dependentes de plataforma, onde nao existe linkagem durante o runtime enquanto em Java isso � excecao. > 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 :) > 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? Curiosidade: em C# um primitivo � um objeto, mas ele *tamb�m* � uma struct, logo pode ser passado por referencia _e_ por valor. Sim, ela tamb�m tem muitas incoer�ncias :) > > N�o entendi patavinas... 8-P... Manda info sobre "delegates"... 8-) > > Mas usar ponteiros numa linguagem OO com m�quina virtual para mim � uma > aberra��o. Ponteiros n�o fazem falta, que o diabo os carregue... 8-) > > Eles s�o sempre a minha �ltima op��o. As delegates s�o um elemento novo e funcionam como se fossem 'ponteiros OO'. Elas agem por eventos chamando m�todos de outras classes. Em Java, elas podem ser emuladas usando classes internas, mas as classes internas salvo engano nao existem em Java 1.1.x logo pra quem usa applets n�o � t�o legal. A Sun escreveu um white paper falando como as delegates s�o a ess�ncia do Mal (http://java.sun.com/docs/white/delegates.html) que, pra variar, teve resposta da Microsoft em http://msdn.microsoft.com/archive/default.asp?url=/ARCHIVE/en-us/dnarvj/html/msdn_deltruth.asp . D� uma lida nos dois q vc vai entender melhor como funciona. De fato, ponteiros s�o uma aberra��o. Mas tem gente q gosta, fazer o q :) > Se o foreach for o que estou pensando, uma lista de objetos soluciona. > Logo, � apenas a��car sint�tico. Se n�o me engano, a java.util.Collections deve ter alguns trecos para isso, mas de qualquer forma vc teria que instanci�-la antes de fazer qualquer coisa. Eu acho q uma palavra-chave da linguagem padr�o seria muito mais r�pido. > A��car sint�tico para mim sempre foi tido como conveni�ncia. Algo > desej�vel, mas n�o imprescind�vel. Logo n�o vejo como definir a > superioridade de uma linguagem com base nisto. [...] > Mas SOAP, meu... Tremendo desperd�cio de largura de banda!!! RPCs com > XML!! 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. Logo, linguagicamente :P acredito q a C# tem muitas vantagens em cima de seu concorrente justamente por causa desse trade-off. 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 :) -- thiago pimentel | mad scientist | [EMAIL PROTECTED] Assinantes em 03/12/2001: 2394 Mensagens recebidas desde 07/01/1999: 144616 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
