Kiss The Blade wrote: > M4ck wrote: > > S� complementando: o Kernel do Linux � escrito em assembly e C, > > n�o h� suporte a OO nele, isto �, voc� n�o pode escrever um > > driver para Linux em C++ e coloc�-lo como m�dulo ao kernel. > > Dia desses o Arnaldo falou que o kernel Linux era programado 'de forma' > OO. Queria saber mais detalhes disso. Arnaldo?
Vide msgs anterior. > A C++ foi criada como o 'C com objetos' e foi denominada dessa mesma [...] > linguagem procedural, OO, funcional, whatever. A STL s� fez piorar isso. Pra quem gosta de C (eu gosto, s� que prefiro usar a ferramenta certa para o trabalho certo, logo aceito que outras linguagens como Pascal, Lisp, Java ou mesmo xBase tamb�m merecem um lugar ao sol, e tbm entre minhas orelhas), procurem se informar sobre o ObjectiveC. � muito interessante. Muito mesmo. Visitem http://gnustep.org/resources/resources.html e d�em uma minerada por l�. > Vamos discutir OO entao. Java � OO, mas nao totalmente pois ainda usa > tipos primitivos. Em Java, um int � um int e acabou. Nope. Vc tem os encapsulamentos dos primitivos em objetos. Que podem ou n�o ser usados, � crit�rio do programador. Estou trabalhando num compilador de uma linguagem orientada � extra��o de dados, logo estou estudando Java e reflex�o at� as entranhas (n�o que esteja entendendo muita coisa... heheehahahah). > Na C#, um int e > todos os outros tipos sao derivados de um ancestral comum q � um objeto. �timo. Logo, qualquer sominha implica em instancia��o e dereferencia��o de pelo menos dois objetos... Prefiro a abordagem de Java. "USe a ferramenta certa para a tarefa certa". > Como a variavel 'a' � um tipo primitivo em Java, o objeto Integer teria > que ser instanciado (transparentemente pois faz parte do balaio padr�o > de java.lang), e seu metodo parseInt() chamado gerando overhead, pois > teria q alocar memoria para a variavel, alocar mais memoria para o > objeto q contem o metodo conversor, e executar o metodo conversor. Mas vc descreveu a forma como *toda* linguagem orientada � objetos trabalha. O fato da C# esconder isto de vc usando a��car sint�tico n�o muda isto... > Na > C#, 'a' � um tipo OO e logo � tambem um objeto com seus proprios metodos > q sao alocados em memoria durante o runtime, logo nao � preciso chamar > terceiros para efetuar a conversao, entao ele age com a propria memoria > alocada para o 'objeto' a. Por outro lado, em Java se vc n�o precisar "objetizar" os primitivos, vc simplesmente n�o VAI carregar em mem�ria os objetos e o c�digo dos encapsulamentos. Logo, este overhead s� � um "problema" quando vc precisa dos encapsulamentos. Em C#, este overhead � "padr�o de f�brica", vc n�o pode fugir dele. 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. 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. Objetos com m�todos est�ticos � um nome pomposo para a boa e velha "Biblioteca de Fun��es". > Falando em conversao, Java n�o tem > boxing/unboxing, logo eu teria q fazer conversao manual de tipos por > valor e tipos por referencia, enquanto na C# isso � autom�tico. Voltando > a falar em tipos, em Java nao existem tipos unsigned. Bicho, entrei em �rbita aqui. Se poss�vel, manda um link sobre (un)?boxing que eu quero dar uma olhada. Quanto � falta de tipos unsigned, concordo com vc. Faz falta sim. > Java n�o tem defines. Logo, nao tem compilacao condicional a nao ser q > vc use produtos de terceiros. 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. O uso adequado de Interfaces resolve este, e muitos outros pepinos de forma elegante. > Java nao faz switch com strings. Porque Java s� faz switch com tipos primitivos. Em Java, strings s�o objetos (mas isto � transparente via a��car sint�tico). Uma cr�tica mais adequada � "Java n�o faz switch com objetos". Nunca precisei usar isto, mas pode ser sim uma cr�tica v�lida. > Java n�o tem atributos ('definicoes' paralelas em tempo de execucao de > metodos. Por exemplo, um mesmo metodo pode fazer duas coisas diferentes > durante o runtime dependendo de seu atributo q � checado via reflex�o). � s� a��car sint�tico. Mas acaba fazendo alguma falta sim. As interfaces das minhas classes em Object Pascal (aka, Delphi) costumam ser bem mais elegantes que as equivalentes em Java. > Nem passagem por referencia. Nem enums. Java tb nao tem propriedades > verdadeiras, pois vc tem q emular com 'get' e 'set', implicando em > escrever dois metodos diferentes. Todo objeto em Java � passado por refer�ncia. Se � importante para vc trabalhar com os primitivos (que sempre s�o por valor) como refer�ncia, instancie-os como objetos e trabalhe-os assim. Quanto �s propriedades, bemmm... Vale o mesmo coment�rio dos atributos acima. Faz falta sim, A falta de enums pode ser hackeada com interfaces, mas � um hack. enums fazem muita falta, ao menos para mim. > Java n�o tem delegates. Delegates servem para a maioria dos usos dos > ponteiros das outras duas linguagens, ou seja, vc pode usar um delegate > para criar um 'apontador' para o codigo de uma segunda classe. Em Java, > vc teria q instanciar um objeto manualmente, consumindo mais memoria e > linhas de programacao. 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. > Java n�o tem structs. Mas structs s�o mera curiosidade hist�rica q > linguagens OO tornam obsoletas. Java tb nao tem goto. Gra�as a Deus :) 8-) > Java n�o tem foreach. Nem sobrecarga de operadores. Nem metodos com > numero variavel de parametros. Se o foreach for o que estou pensando, uma lista de objetos soluciona. Logo, � apenas a��car sint�tico. Quanto � sobrecarga de operadores e n�mero vari�vel de par�metros, eu considero isto uma vantagem!!!!!!!! 8-) Sobrecarga de operadores, se usada de forma correta, � muito interessante. Pena que ningu�m use isto de forma correta... 8-) M�todos com par�metros vari�veis podem ser tranq�ilamente substitu�dos com sobrecarga de m�todos. N�o vejo absolutamente nenhuma necessidade de se ter ambos os m�todos implementados numa linguagem. > O namespace de um pacote Java est� 'travado' no seu arquivo de > declaracao. Isto � um saco mesmo. Mas � uma restri��o que visa seguran�a, assim como o fato de uma applet s� poder se comunicar com o site de onde ela foi chamada... > De fato, como linguagem a C# *�* superior. 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. L�gico, alguns t�picos acima s�o obscuros para mim, logo n�o posso (ainda) negar sua afirma��o. > Quando usar C#: Hoje, qd a linha de deployment do seu programa soh passa > por produtos Microsoft. Mais tarde, qd existirem implementacoes de C# > para outras plataformas e frameworks funcionais (acreditem, nao vai > demorar muito. Foi assim com o COM, o SOAP, e tudo mais q todo mundo > dizia q nao ia dar certo) COM v� l�... N�o � nenhum CORBA, mas sua principal vantagem � essa mesma... 8-) Pra quem ainda gosta de DDE (como eu), COM � �til sim. Mas SOAP, meu... Tremendo desperd�cio de largura de banda!!! RPCs com XML!! 8-P Com tanta RFC definindo interc�mbio de tipos b�sicos de dados, com convers�es simples e otimiza��o de largura de banda (pow, man�!!! basta uma fun��ozinha conversora, que por sinal poder estar na biblioteca padr�o!!!), SOAP � uma estupidez sim. -- []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 03/12/2001: 2399 Mensagens recebidas desde 07/01/1999: 144510 Historico e [des]cadastramento: http://linux-br.conectiva.com.br Assuntos administrativos e problemas com a lista: mailto:[EMAIL PROTECTED]
