Kiss The Blade wrote: > Mas � �bvio que Strings funcionam dessa forma, pq o tipo String > diferente dos outros est� dentro do modelo OO. Vc afirmou que ints em > Java fazem parte do modelo OO pelo simples fato de q podem ser > encapsulados quando disse que: > > K Vamos discutir OO entao. Java � OO, mas nao totalmente pois ainda usa > K tipos primitivos. Em Java, um int � um int e acabou. > > L Nope. Vc tem os encapsulamentos dos primitivos em objetos. Que podem > ou > L n�o ser usados, � crit�rio do programador.
Mas � isto a�... Falei dos encapsulamentos. At� onde eu entendo, a tradu��o de "wrapper" � envolt�rio (de acordo com http://babel.altavista.com), que no meu entender � sin�nimo de encapsulamento... Mais tarde eu ainda disse: "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." Eu n�o enxergo onde afirmei que os java.lang.[Tipo] substituem plenamente os primitivos. EU apenas afirmei que os encapsulavam, para que se possa instanci�-los como objetos quando necess�rio... Logo achei que a frase original fosse clara. Esta frase, mais aquele exemplo besta da soma de java.lang.Integer derreferenciando na marra os diabos das inst�ncias, procurava provar que o recurso existe em Java. S� que feito "na marra". � uma baita incoer�ncia em rela��o � teoria OO. Mas n�o o � com a filosofia pr� efici�ncia do Gosling. > Ah, vc tb afirmou que eu estava errado em dizer q Strings nao existem > como vetor de primitivos dentro da plataforma Java. Pois bem, se vc > instalou seu SDK completo, l� tem um arquivo src.jar. Descompacte e l� > dentro em src/lang/String.java tem o codigo fonte da mesma implementacao > da api java.lang.String documentada nos javadocs. Leia a partir da linha > 181. E tamb�m escrevi : "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.". Talvez por este motivo Strings seja final. Como diabos vc imagina que se implementa um vetor de inteiros, j� que vetores s�o eles mesmo objetos? Na teoria de um jeito. Na pr�tica, de outro mais eficiente. Como vetores tbm s�o finals, n�o faz diferen�a. Ningu�m "percebe" a diferen�a... > Adendo ao seu primeiro paragrafo: ningu�m � louco de fazer manipula��o > num�rica pura em Java. Quando isso � essencial, todo mundo chama uma DLL > dependente de plataforma via JNI. Se eu for fazer uma biblioteca din�mica nativa (Linux n�o usa DLLs...8-P), pra que diabos ent�o eu vou me dar ao trabalho de programar em Java? Vou logo pro ObjectiveC ou C++. Uso Java para construir programas independentes de plataforma, onde ainda a considero imbat�vel. Mas para aplica��es dependentes de plataforma, ela � uma bela meleca. Nestes termos, prefiro correr atr�s do modelo de objetos da Borland. Falando nisso, olhem isto aqui : http://anfyteam.com/index.html Engine 3D (n�o � a implementa��o nativa OpenGL da Sun n�o, � tudo software mesmo!), filtros, plasmas. Tudo 100% java. Seria muito interessante rescrever estes mesmos programas em C# e comparar os resultados... > O SDK pode ser baixado em http://www.microsoft.com/net. S�o 123MB e > provavelmente nao funfar� no seu Win95 =( Ouch... Ponto pro Software Livre... 8-P > > 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... > > Eu n�o disse isso. Eu disse que o que estava dentro de java.lang podia > ser acessado transparentemente mas nem por isso deixavam de ser > instanciados. [...] Granted. Mas nem por isto precisam ser instanciados. Eu n�o estava falando de instancia��o, mas de chamadas � s�mbolos est�ticos. Granted de novo, NESTE par�grafo isto n�o ficou claro. Mas posteriormente eu martelei isto novamente, ao que vc respondeu: <quote> > 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 n�o 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.[...] </quote> O que vc queria que eu pensasse ent�o? Vc diz claramente que n�o existem objetos encapsuladores, mas depois fala que existem os wrappers... que me parecem ser a mesma coisa... Vc afirma tbm que m�todos est�ticos implicam em instancia��o, o que nem sempre � verdade... J� que n�o convencia por palavras, fui pro c�digo. Of Course os exemplos eram simpl�rios. Qual a necessidade de complicar? -- []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: 2383 Mensagens recebidas desde 07/01/1999: 145041 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
