Oracle pode estar interessada em comprar a Zend, Sleepycat e JBoss
“A Business Week publicou uma reportagem onde mostra que a Oracle planeja comprar três empresas que são responsáveis por produtos open-source sendo elas: Zend(PHP) Sleepcat(Database) Jboss(Middleware) A Oracle pretende controlar essas linguagens para obter vantagens na competição com outras companhias que atuam no segmento de business applications. De acordo com a reportagem a Oracle não planejaria cobrar de seus clientes pelo acesso a programas feitos com as linguagens de código aberto, mas sim obter exclusividade no fornecimento de suporte técnico ao uso destas linguagens. Atualmente este tipo de suporte pode ser oferecido por qualquer empresa. As informações contidas nessa reportagem causaram uma grande discurssão por parte dos desenvolvedores que temem mudanças na forma de licenciamento das tecnologias envolvidas na venda das empresas responsáveis por sua manutenção.” A nota foi enviada por Leonardo da Silva Calado (lscaladoΘlscalado·com) , que enviou este link para mais detalhes.
A notícia da Info sobre o assunto começa assim: "A revista norte-americana Business Week desencadeou uma onda de boatos ao publicar, na quinta-feira dia 9, reportagem anunciando que a gigante Oracle planeja comprar três companhias de software livre".
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Troll
14/02/06 8:50
Enterrar o PHP uhuuu: Espero que a Oracle nos faça o favor de enterrar o PHP ahahahah
Comentário de ElderBahamut
14/02/06 9:35
uma linguagem de script, + um: uma linguagem de script, + uma empresa de database como a innoDB e um application server..., isso impacta consideravelmente nos produtos da Oracle principalmente o OCS, onde o indice de INSATISFAÇÃO acredito que seja um dos maiores dos AppServers, talvez não seja uma boa ideia investir em projetos tomando de base o OCS pois pode vir muita mudança por ai
Comentário de anonymous jose da costa
14/02/06 10:02
perda para o PHP: Acredito que nessa (e|he)storio toda o PHP sairia perdendo, uma vez que seu ritimo de crescimento eh excelente, no mais, serah muito provável que a Oracle farah o que a macromedia fez com o Cold Fusion(CF) colocando-o sob o java, em nome de uma maior integracao entre aplicacoes ou escalabilidade sei lah o que foi isso..., o que em minha opinião simplesmente destruiria o PHP, assim como foi com CF.
Fora a transação financeira naum consigo enxergar nenhuma vantagem para ZEND que hoje é um dos grandes nomes, qndo se fala em SL, no mundo. Pelo jeito terei que aprender Perl e Python, pra ter a certeza que não precisar usar uma linguagem hibrida, mais do que já eh, soh que agora entre uma linguagem que a muito fora boa com uma desgraça que é o Java :P
é apenas minha opinião, dê a sua sem atacar a minha.
Fora a transação financeira naum consigo enxergar nenhuma vantagem para ZEND que hoje é um dos grandes nomes, qndo se fala em SL, no mundo. Pelo jeito terei que aprender Perl e Python, pra ter a certeza que não precisar usar uma linguagem hibrida, mais do que já eh, soh que agora entre uma linguagem que a muito fora boa com uma desgraça que é o Java :P
é apenas minha opinião, dê a sua sem atacar a minha.
Comentário de Copernico Vespucio
14/02/06 11:02 - usuário registrado #4868
"Oracle JBoss" seria ruim para todos: Atualmente, pequenas empresas e indivíduos podem oferecer suporte full ao JBoss. Para ter o aval da empresa é preciso fazer um curso (caríssimo, mas ao menos disponível) e comprar os manuais oficiais (os avançados, os básicos são gratuítos).
A primeira coisa que a Oracle iria fazer ao pôr as mãos no JBoos seria cancelar essa possibilidade.
Isso é ruim para os profissionais, pois a indisponibilidade de documentação vai tornar a concorrência desleal, e é ruim para os clientes, que precisarão se restringir ao suporte da Oracle.
Mas nem tudo é tenebroso: a JBoss LLC é "carne de pescoço" pra caramba, sabe o produto que tem e o quanto pode ganhar a longo prazo, então não vai se entregar tão fácil assim. O Apache Gerônimo é ótimo (além de mais simples de usar) mas por enquanto não tem a maturidade do JBoss, nem a sua base de usuários satisfeitos.
Em relação ao PHP talvez ela até faça algo de positivo para a linguagem, botando ordem no "samba do afro-brasileiro insano" que são suas bibliotecas, criando uma API "oficial" mais organizada e abrangente. Também deve melhorar a implementação da biblioteca de acesso ao Oracle (mas provavelmente vai fazer questão de deixar o suporte a MySQL e PostGres como está, naturalmente).
pra ter a certeza que não precisar usar uma linguagem hibrida
Integrar PHP com Java??? Meu Deus do céu: pra quê? A Oracle vai muito bem com Java obrigado, não precisa costurar essa traquizonga nele não...
A primeira coisa que a Oracle iria fazer ao pôr as mãos no JBoos seria cancelar essa possibilidade.
Isso é ruim para os profissionais, pois a indisponibilidade de documentação vai tornar a concorrência desleal, e é ruim para os clientes, que precisarão se restringir ao suporte da Oracle.
Mas nem tudo é tenebroso: a JBoss LLC é "carne de pescoço" pra caramba, sabe o produto que tem e o quanto pode ganhar a longo prazo, então não vai se entregar tão fácil assim. O Apache Gerônimo é ótimo (além de mais simples de usar) mas por enquanto não tem a maturidade do JBoss, nem a sua base de usuários satisfeitos.
Em relação ao PHP talvez ela até faça algo de positivo para a linguagem, botando ordem no "samba do afro-brasileiro insano" que são suas bibliotecas, criando uma API "oficial" mais organizada e abrangente. Também deve melhorar a implementação da biblioteca de acesso ao Oracle (mas provavelmente vai fazer questão de deixar o suporte a MySQL e PostGres como está, naturalmente).
pra ter a certeza que não precisar usar uma linguagem hibrida
Integrar PHP com Java??? Meu Deus do céu: pra quê? A Oracle vai muito bem com Java obrigado, não precisa costurar essa traquizonga nele não...
Comentário de Fernando Henrique Correa
14/02/06 11:04
O Controle do Open Souce: Sou Desenvolvedor de aplicações em PHP.
Creio que com esse, artigo posso dizer que estamos perdendo o controle sobre os nosso OpenSouces, deixando que empresas abafem seu crescimento e desenvolvimento.
Não acho que a Oracle, apenas cuidaria dos suporte técnico a clientes(php), mais sim manipularia o direcionamento de uma vasta comunidade de desenvolvedores em benefício da própria Oracle.
Em contraponto a isso será que eles como empresa investiriam na comunidade? Deixariam a comunidade crescer como tem de ser? Ou colocariam limites???
Creio que com esse, artigo posso dizer que estamos perdendo o controle sobre os nosso OpenSouces, deixando que empresas abafem seu crescimento e desenvolvimento.
Comentário de Copernico Vespucio
14/02/06 11:11 - usuário registrado #4868
PHP e Zend: A Zend impulsiona, e centraliza o desenvolvimento do PHP, mas não o controla (o que é um problema, uma plataforma de desenvolvimento precisa de uma forma de controle, senão cresce desordenadamente).
Isso significa que, mesmo que a Oracle compre a Zend, a comunidade (ou outra empresa SL) pode pegar a atual implementação do PHP e continuar o desenvolvimento a partir daí. Infelizmente teríamos o "Oracle PHP" e o "Community PHP", dispersando os esforços na plataforma e prejudicando principalmente os desenvolvedores.
Esse tipo de "fork" é justamente o que a Sun tentou evitar inicialmente quando a IBM fez pressão para a liberação do Java. Mostra que a GPL é boa para produtos, mas é preciso ter regras melhores para padrões, para que nos defendamos dos "processos de fagocitose" por parte das grandes corporações.
Isso significa que, mesmo que a Oracle compre a Zend, a comunidade (ou outra empresa SL) pode pegar a atual implementação do PHP e continuar o desenvolvimento a partir daí. Infelizmente teríamos o "Oracle PHP" e o "Community PHP", dispersando os esforços na plataforma e prejudicando principalmente os desenvolvedores.
Esse tipo de "fork" é justamente o que a Sun tentou evitar inicialmente quando a IBM fez pressão para a liberação do Java. Mostra que a GPL é boa para produtos, mas é preciso ter regras melhores para padrões, para que nos defendamos dos "processos de fagocitose" por parte das grandes corporações.
Comentário de adilson
14/02/06 11:15 - usuário registrado #239
"Samba do afro-brasileiro insano": Essa foi hilária em um sentido sarcástico-exagerado-politicamente-correto :)
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca
Comentário de Thiago Mata
14/02/06 11:27
especulações: Considerar o desuso de uma ferramenta que se tem adequado cada vez mais ao mercado com potencialidade e rendimento e organização complexa ( por exemplo, http://www.phppatterns.com/docs/design/hello_world_in_patterns ) é defender uma visão meramente superficial de que a ferramenta da qual se desconhece o uso, ou o bom uso é algo que deve ser desestimulado a sua continuidade.
O que se pode ver no mercado é justamente um crescimento de sites que anunciam e estimulam o bom uso destas ferramentas tal qual, no contexto, o www.phpclasses.org.
Não aceitar a evolução de uma linguagem concorrente pelo seu desconhecimento é uma visão hipócrita que tenta reger os métodos da evolução das linguagens de programação segundo o seu conhecimento / falta dele. Um desenvolvedor deve procuro estimular o bom uso de qualquer ferramenta dentro do seu foco de aplicação auxiliando-o se possível. Defender bandeiras ideológicas de melhores ou piores ferramentas ( sem uma analise profunda de qual é a aplicação ) é uma atitude típica de quem só conhece alguma delas.
A atitude da Oracle demonstra mais uma vez que este mercado pode ser de grande lucratibilidade, pois, quer se goste ou não, tem conquistado desde empresas de exigências organizacionais mínimas até as que desejam fazer softwares complexos e bem organizados para web.
Ao contrario do que muitas vezes se crê, existe lucro no software livre, com os serviços pagos de manutenção e assistência técnica de programas de código aberto. Aparentemente a Oracle só está tentando entrar neste mercado que tem se tornado cada dia mais interessante.
O que se pode ver no mercado é justamente um crescimento de sites que anunciam e estimulam o bom uso destas ferramentas tal qual, no contexto, o www.phpclasses.org.
Não aceitar a evolução de uma linguagem concorrente pelo seu desconhecimento é uma visão hipócrita que tenta reger os métodos da evolução das linguagens de programação segundo o seu conhecimento / falta dele. Um desenvolvedor deve procuro estimular o bom uso de qualquer ferramenta dentro do seu foco de aplicação auxiliando-o se possível. Defender bandeiras ideológicas de melhores ou piores ferramentas ( sem uma analise profunda de qual é a aplicação ) é uma atitude típica de quem só conhece alguma delas.
A atitude da Oracle demonstra mais uma vez que este mercado pode ser de grande lucratibilidade, pois, quer se goste ou não, tem conquistado desde empresas de exigências organizacionais mínimas até as que desejam fazer softwares complexos e bem organizados para web.
Ao contrario do que muitas vezes se crê, existe lucro no software livre, com os serviços pagos de manutenção e assistência técnica de programas de código aberto. Aparentemente a Oracle só está tentando entrar neste mercado que tem se tornado cada dia mais interessante.
Comentário de Copernico Vespucio
14/02/06 12:01 - usuário registrado #4868
Concordo e não Concordo...: Um desenvolvedor deve procuro estimular o bom uso de qualquer ferramenta dentro do seu foco de aplicação auxiliando-o se possível.
Nisso eu concordo com vc. Uma coisa é não usar uma plataforma, não conhecer, criticar coisas nela. Outra coisa é combater sua evolução. Evolução de uma plataforma de desenvolvimento, seja ela qual for, significa evolução do conceito de programação como um todo e é bom pra todo mundo. Quem trabalha merece palmas, independentemente de qual seja seu trabalho.
Por exemplo (falo pq conheço PHP suficientemente para isso, já ministrei aulas para um pessoal da COBRA): a API do PHP é muito fragmentada, muita gente fazendo bibliotecas diferentes para o mesmo objetivo, muitas "libraries" e poucos frameworks, nenhum controle (leia-se "controle" como "comum acordo da comunidade") de sua evolução. Esse é o maior problema do PHP pra mim. Mas isso não significa que eu possa dizer por aí: "Não usem PHP". Eu não uso mais, nem recomendo aos meus clientes, mas não nego seu valor.
Em relação a posição de que Oracle vai ser "bom" para os desenvolvedores PHP eu não concordo. Ela pode melhorar o PHP em seu próprio benefício, mas se isso vai reverter positivamente para sua comunidade eu não sei.
Não há nada de errado com uma empresa que amplia sua influência em uma plataforma de desenvolvimento. O problema é ela se tornar a "dona da bola": Fagocitose.
Isso me preocupa muito. PHP está desprotegida contra a Oracle. Python está desprotegida frente à M$. Suas comunidades deveriam se organizar melhor com o objetivo de proteger seus interesses.
Nisso eu concordo com vc. Uma coisa é não usar uma plataforma, não conhecer, criticar coisas nela. Outra coisa é combater sua evolução. Evolução de uma plataforma de desenvolvimento, seja ela qual for, significa evolução do conceito de programação como um todo e é bom pra todo mundo. Quem trabalha merece palmas, independentemente de qual seja seu trabalho.
Por exemplo (falo pq conheço PHP suficientemente para isso, já ministrei aulas para um pessoal da COBRA): a API do PHP é muito fragmentada, muita gente fazendo bibliotecas diferentes para o mesmo objetivo, muitas "libraries" e poucos frameworks, nenhum controle (leia-se "controle" como "comum acordo da comunidade") de sua evolução. Esse é o maior problema do PHP pra mim. Mas isso não significa que eu possa dizer por aí: "Não usem PHP". Eu não uso mais, nem recomendo aos meus clientes, mas não nego seu valor.
Em relação a posição de que Oracle vai ser "bom" para os desenvolvedores PHP eu não concordo. Ela pode melhorar o PHP em seu próprio benefício, mas se isso vai reverter positivamente para sua comunidade eu não sei.
Não há nada de errado com uma empresa que amplia sua influência em uma plataforma de desenvolvimento. O problema é ela se tornar a "dona da bola": Fagocitose.
Isso me preocupa muito. PHP está desprotegida contra a Oracle. Python está desprotegida frente à M$. Suas comunidades deveriam se organizar melhor com o objetivo de proteger seus interesses.
Comentário de hamacker
14/02/06 13:15 - usuário registrado #168
A respeito de _se_ ocorrer a: A respeito de _se_ ocorrer a compra da Zend, bem apenas o portifólio da Zend que já é voltada para o lado comercial passaria para o controle da Oracle. Talvez isso seja bom, porque muita gente gostaria de estar nas mãos da Oracle e não na mao da Zend. Seria uma excelente jogada da Oracle, pois a Zend parece representar bons lucros e novas possibilidades num mercado estagnado da Oracle.
Quanto a linguagem php eu não me preocuparia, afinal durante tanto tempo com informatica e programação eu aprendi que o mercado acaba equalizando e achando o equilibrio mesmo que seja a substituição do php por outra como aconteceu ao clipper quando foi comprado pela CA.
Quanto a linguagem php eu não me preocuparia, afinal durante tanto tempo com informatica e programação eu aprendi que o mercado acaba equalizando e achando o equilibrio mesmo que seja a substituição do php por outra como aconteceu ao clipper quando foi comprado pela CA.
Comentário de dimiclip
14/02/06 14:04 - usuário registrado #5392
não é bem assim...: A Zend "poderá" ser comprada. ZEND != PHP. A Zend são 2 mentes, Zeev, Andi, brilhantes por sinal. Mas existen N outras pessoas que conhecem o Zend Engine. "Caso" a Oracle compre a Zend, a única coisa que poderia fazer é mudar o licenciamento do Zend Engine, nada que um fork da comunidade não resolva. O PHP continuaria a ser livre...
O Clipper não era livre, portanto é o mesmo que comparar laranjas com pepinos...
O Clipper não era livre, portanto é o mesmo que comparar laranjas com pepinos...
Comentário de Copernico Vespucio
14/02/06 14:13 - usuário registrado #4868
depende...: nada que um fork da comunidade não resolva
Depende de qual dos dois forks tiver mais força.
Se a versão da Oracle for a efetivamente adotada pela indústria de TI, a versão livre vai se tornar uma brilhante, eficiente e elaborada "coisa de nerd", ou versão "alternativa".
Depende de qual dos dois forks tiver mais força.
Se a versão da Oracle for a efetivamente adotada pela indústria de TI, a versão livre vai se tornar uma brilhante, eficiente e elaborada "coisa de nerd", ou versão "alternativa".
Comentário de dimiclip
14/02/06 14:31 - usuário registrado #5392
veja bem...: Duvido que a versão tocada pela Oracle creça mais rápido ou tenha mais força do que a versão tocada pela comunidade... Hoje a comunidade de desenvolvedores PHP é bem maior do que a Zend.
Vc está chamando o Linux de "coisa de nerd" também ?
Vc está chamando o Linux de "coisa de nerd" também ?
Comentário de hamacker
14/02/06 14:56 - usuário registrado #168
A Zend "poderá" ser comprada: A Zend "poderá" ser comprada. ZEND != PHP. A Zend são 2 mentes, Zeev, Andi, brilhantes por sinal. Mas existen N outras pessoas que conhecem o Zend Engine. "Caso" a Oracle compre a Zend, a única coisa que poderia fazer é mudar o licenciamento do Zend Engine, nada que um fork da comunidade não resolva. O PHP continuaria a ser livre...
Por isso eu volta a _repetir_, o mercado acaba se equalizando, se for a vontade do mercado, idealizadores prosseguir com o php "forkado" assim será, se for continuar com a versao php "oracleado" assim será, se for eliminar o php assim será, o mercado e as pessoas vao acabar decidindo isso.
Algo semelhante ocorreu com o Interbase onde a Borland (se ainda nao mudou de nome :)) liberou o IB6 Opensource e depois relançou a versao 6.5 só que fechado, a comunidade antecipadamente já tinha "forkado" e dado inicio ao Firebird que antes era apenas uma cópia do IB6 com algumas funcoes extras e hoje já é um outro produto completamente diferente. Inclusive a versao 2 (alfa) dá adeus ao código antigo da Borland. Nesse caso deu certo, como eu disse o mercado acaba se adaptando e equalizando por sí só as soluções boas ou más dependendo do ponto de vista de quem olha.
Por isso eu volta a _repetir_, o mercado acaba se equalizando, se for a vontade do mercado, idealizadores prosseguir com o php "forkado" assim será, se for continuar com a versao php "oracleado" assim será, se for eliminar o php assim será, o mercado e as pessoas vao acabar decidindo isso.
Algo semelhante ocorreu com o Interbase onde a Borland (se ainda nao mudou de nome :)) liberou o IB6 Opensource e depois relançou a versao 6.5 só que fechado, a comunidade antecipadamente já tinha "forkado" e dado inicio ao Firebird que antes era apenas uma cópia do IB6 com algumas funcoes extras e hoje já é um outro produto completamente diferente. Inclusive a versao 2 (alfa) dá adeus ao código antigo da Borland. Nesse caso deu certo, como eu disse o mercado acaba se adaptando e equalizando por sí só as soluções boas ou más dependendo do ponto de vista de quem olha.
Comentário de Copernico Vespucio
14/02/06 18:04 - usuário registrado #4868
eu vi, mas não acredito: Duvido que a versão tocada pela Oracle creça mais rápido ou tenha mais força do que a versão tocada pela comunidade
Espero pelo bem da plataforma que vc. esteja correto. Por meu lado eu lembro que a experiência da Oracle em forçar padrões é grande (SQL-99, empurrar o SQLJ pelo JCP adentro, etc).
Vc está chamando o Linux de "coisa de nerd" também ?
Já foi considerado assim, lembra? :-D Graças aos esforços de muita gente e a ajuda do grande escovador de bits lá no céu, conseguimos reverter esse quadro!
Espero pelo bem da plataforma que vc. esteja correto. Por meu lado eu lembro que a experiência da Oracle em forçar padrões é grande (SQL-99, empurrar o SQLJ pelo JCP adentro, etc).
Vc está chamando o Linux de "coisa de nerd" também ?
Já foi considerado assim, lembra? :-D Graças aos esforços de muita gente e a ajuda do grande escovador de bits lá no céu, conseguimos reverter esse quadro!
Comentário de marcosalex
14/02/06 20:56 - usuário registrado #250
Oracle: "A primeira coisa que a Oracle iria fazer ao pôr as mãos no JBoos seria cancelar essa possibilidade."
Será? A Oracle disponibiliza o download de todos os seus produtos (sem excessão) e toda a documentação e apostila de treinamento. Sem falar que na maioria das suas palestras eles até distribuem um kit com uns 15 CDs de programas Oracle em todas as plataformas pros participantes (gratuito).
E recentemente eles ainda disponibilizaram uma versão do Oracle free para uso comercial ( a limitação é que o banco não pode passar de 4 Gb, mais do que suficiente para a maioria das pequenas empresas).
Meu palpite (agora é opinião minha) é que eles devem investir em uma boa API para o PHP e em uma boa IDE para facilitar o desenvolvimento, tal qual eles fizeram com o Java, e tal qual a Borland fez com o C# e com o Java (diga-se de passagem, ninguem faz IDEs tão produtivas como as da Borland).
Haskell developer
Será? A Oracle disponibiliza o download de todos os seus produtos (sem excessão) e toda a documentação e apostila de treinamento. Sem falar que na maioria das suas palestras eles até distribuem um kit com uns 15 CDs de programas Oracle em todas as plataformas pros participantes (gratuito).
E recentemente eles ainda disponibilizaram uma versão do Oracle free para uso comercial ( a limitação é que o banco não pode passar de 4 Gb, mais do que suficiente para a maioria das pequenas empresas).
Meu palpite (agora é opinião minha) é que eles devem investir em uma boa API para o PHP e em uma boa IDE para facilitar o desenvolvimento, tal qual eles fizeram com o Java, e tal qual a Borland fez com o C# e com o Java (diga-se de passagem, ninguem faz IDEs tão produtivas como as da Borland).
Haskell developer
Comentário de Gato do Deserto
14/02/06 22:10
é mais uma das maldições da internet ...: discuRssão é ph***
é mais uma das maldições da internet ...
assim como "mais" em lugar de "mas" (Fui abrir a porta MAIS tava trancada) - típico carioca que coloca "i" onde não tem, como em naiscimento .... verdade ! peça para qualquer carioca pronunciar nas-ci-mento ! eles não conseguem!
assim como "agente" ( Agente foi e voltou )
além do fonético CD-RUM ou CD-ROOM - coisa de paulista e carioca - ... quando deveria ser CD-RÔM !!
é mais uma das maldições da internet ...
assim como "mais" em lugar de "mas" (Fui abrir a porta MAIS tava trancada) - típico carioca que coloca "i" onde não tem, como em naiscimento .... verdade ! peça para qualquer carioca pronunciar nas-ci-mento ! eles não conseguem!
assim como "agente" ( Agente foi e voltou )
além do fonético CD-RUM ou CD-ROOM - coisa de paulista e carioca - ... quando deveria ser CD-RÔM !!
Comentário de nemesis
15/02/06 7:24 - usuário registrado #1514
involução: "Evolução de uma plataforma de desenvolvimento, seja ela qual for, significa evolução do conceito de programação como um todo e é bom pra todo mundo."
Conversa fiada! BASIC evoluiu pouco e mal durante todos esses anos e nenhuma de suas "evoluções" representa um marco significativo ou quanto menos um avanço para o "conceito de programação como um todo". As "evoluções" de Java consistem basicamente em reinventar conceitos introduzidos em Lisp ( closures, na forma de classes anônimas ) ou C++ ( generics, o template dos pobres )... etc
"Quem trabalha merece palmas, independentemente de qual seja seu trabalho."
Então, palmas para Lula e sua equipe de primeira. ;)
"a API do PHP é muito fragmentada, muita gente fazendo bibliotecas diferentes para o mesmo objetivo, muitas 'libraries' e poucos frameworks,"
Eu não vejo problema nisso, afinal um framework _é_ uma biblioteca. Meu problema com PHP é que ele não possui nenhum mecanismo para controle de namespaces ( módulos ), como C. Seus pares -- Perl, Python e Ruby -- possuem grandes mecanismos para tal e isso se traduz em uma modularização muito boa...
"PHP está desprotegida contra a Oracle. Python está desprotegida frente à M$. Suas comunidades deveriam se organizar melhor com o objetivo de proteger seus interesses."
deveriam formar uma JCP presidida por uma empresa. ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Conversa fiada! BASIC evoluiu pouco e mal durante todos esses anos e nenhuma de suas "evoluções" representa um marco significativo ou quanto menos um avanço para o "conceito de programação como um todo". As "evoluções" de Java consistem basicamente em reinventar conceitos introduzidos em Lisp ( closures, na forma de classes anônimas ) ou C++ ( generics, o template dos pobres )... etc
"Quem trabalha merece palmas, independentemente de qual seja seu trabalho."
Então, palmas para Lula e sua equipe de primeira. ;)
"a API do PHP é muito fragmentada, muita gente fazendo bibliotecas diferentes para o mesmo objetivo, muitas 'libraries' e poucos frameworks,"
Eu não vejo problema nisso, afinal um framework _é_ uma biblioteca. Meu problema com PHP é que ele não possui nenhum mecanismo para controle de namespaces ( módulos ), como C. Seus pares -- Perl, Python e Ruby -- possuem grandes mecanismos para tal e isso se traduz em uma modularização muito boa...
"PHP está desprotegida contra a Oracle. Python está desprotegida frente à M$. Suas comunidades deveriam se organizar melhor com o objetivo de proteger seus interesses."
deveriam formar uma JCP presidida por uma empresa. ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Ark
15/02/06 8:38
JDeveloper: Concordo com bastante coisa, exceto que acho o JDeveloper inferior à vários IDEs. Acho que seria bem melhor se a Oracle contribuisse com outras ao invés de ficar querendo fazer pra tudo uma versão dela (a la MS).
Comentário de Copernico Vespucio
15/02/06 12:52 - usuário registrado #4868
reverta sua espiral evolutiva: Conversa fiada! BASIC evoluiu pouco e mal durante todos esses anos e nenhuma de suas "evoluções" representa um marco significativo ou quanto menos um avanço para o "conceito de programação como um todo"
Eu estava falando de línguas atualmente mais significativas, mas no passado, mal ou bem, BASIC nos ensinou alguma coisa sobre "simplicidade" (eiii! Eu comecei a programar em BASIC Extended no velho TRS80-CP500, faz muuuito tempo. Não fale mal dele! :-D).
As "evoluções" de Java consistem basicamente em reinventar conceitos introduzidos em Lisp ( closures, na forma de classes anônimas ) ou C++ ( generics, o template dos pobres )... etc
Engula sua língua, rapaz:
Closures não são o mesmo que classes anônimas, embora tenham sintaxe vagamente semelhante. Closures são mais poderosas e a implementação de Closures em Groovy (e provavelmente no futuro J2SE7.0 Dolphin) são ainda mais poderosas que as do Lisp. Closures são o único recurso que considero útil em línguas + dinâmicas como Ruby.
Se vc. tiver o trabalho de ver a especificação do Generics vai perceber que, ao contrário, Java Generics é o "template dos ricos", contando com muito mais recursos do que o primeiro. Estude antes de falar besteira.
Então, palmas para Lula e sua equipe de primeira. ;)
Ao menos a antiga dívida com o FMI está paga, certo? Não bato muitas palmas para este governo, mas meus filhos não vão mais ser caloteiros ao nascer. Mas sem + política nesse fórum, please.
Não é problema PHP ter bibliotecas de terceiros, o problema é isto está fora de controle, sem que se siga nenhuma espécie de padronização comum. (Eu não posso dizer que faltam padrões, pq realmente não faltam: cada desenvolvedor de bibliotecas tem o seu... :-P).
Vc. esqueceu de citar Java como plataforma que tem mecanismo de controle de namespace... :-P
deveriam formar uma JCP presidida por uma empresa. ;)
Primeiro: Eu não acredito que todo este tempo eu estive falando alemão... JCP não tem "presidência" de uma empresa. É um conselho de muitas empresas, assim como ONGs, governos etc. Não há presidente, existe o poder de *voto*, não de *veto*.
Segundo: A organização que falta não é de um orgão controlado por uma empresa (a Oracle pretende fazer isso, ao que parece). O que falta é uma entidade que possua um *processo organizado, com regras bem definidas*. Isso é o que faz a diferença.
Eu estava falando de línguas atualmente mais significativas, mas no passado, mal ou bem, BASIC nos ensinou alguma coisa sobre "simplicidade" (eiii! Eu comecei a programar em BASIC Extended no velho TRS80-CP500, faz muuuito tempo. Não fale mal dele! :-D).
As "evoluções" de Java consistem basicamente em reinventar conceitos introduzidos em Lisp ( closures, na forma de classes anônimas ) ou C++ ( generics, o template dos pobres )... etc
Engula sua língua, rapaz:
Closures não são o mesmo que classes anônimas, embora tenham sintaxe vagamente semelhante. Closures são mais poderosas e a implementação de Closures em Groovy (e provavelmente no futuro J2SE7.0 Dolphin) são ainda mais poderosas que as do Lisp. Closures são o único recurso que considero útil em línguas + dinâmicas como Ruby.
Se vc. tiver o trabalho de ver a especificação do Generics vai perceber que, ao contrário, Java Generics é o "template dos ricos", contando com muito mais recursos do que o primeiro. Estude antes de falar besteira.
Então, palmas para Lula e sua equipe de primeira. ;)
Ao menos a antiga dívida com o FMI está paga, certo? Não bato muitas palmas para este governo, mas meus filhos não vão mais ser caloteiros ao nascer. Mas sem + política nesse fórum, please.
Não é problema PHP ter bibliotecas de terceiros, o problema é isto está fora de controle, sem que se siga nenhuma espécie de padronização comum. (Eu não posso dizer que faltam padrões, pq realmente não faltam: cada desenvolvedor de bibliotecas tem o seu... :-P).
Vc. esqueceu de citar Java como plataforma que tem mecanismo de controle de namespace... :-P
deveriam formar uma JCP presidida por uma empresa. ;)
Primeiro: Eu não acredito que todo este tempo eu estive falando alemão... JCP não tem "presidência" de uma empresa. É um conselho de muitas empresas, assim como ONGs, governos etc. Não há presidente, existe o poder de *voto*, não de *veto*.
Segundo: A organização que falta não é de um orgão controlado por uma empresa (a Oracle pretende fazer isso, ao que parece). O que falta é uma entidade que possua um *processo organizado, com regras bem definidas*. Isso é o que faz a diferença.
Comentário de Copernico Vespucio
15/02/06 12:56 - usuário registrado #4868
só uma correção: Os frameworks da Oracle para Java são sofríveis, apesar do que seu marketing diz.
Se quer um exemplo antigo, lembro o BC4J, o primeiro e pior ORM de todos os tempos.
Se quer um exemplo antigo, lembro o BC4J, o primeiro e pior ORM de todos os tempos.
Comentário de Copernico Vespucio
15/02/06 12:58 - usuário registrado #4868
concordo, mas moderei: Tirando erros de digitação, é realmente importante que procuremos escrever direito em *discussões* como esta.
Mas isso não tem a ver com o assunto, então vou moderar seu comentário, ok?
Quem puder, modere esse meu também, por favor. Para que possamos voltar ao assunto principal.
Mas isso não tem a ver com o assunto, então vou moderar seu comentário, ok?
Quem puder, modere esse meu também, por favor. Para que possamos voltar ao assunto principal.
Comentário de nemesis
15/02/06 13:56 - usuário registrado #1514
re:: "BASIC nos ensinou alguma coisa sobre 'simplicidade'"
não me ponha nesse meio. e não confunda mediocridade com simplicidade.
"Closures não são o mesmo que classes anônimas"
é claro, mas é o mais próximo que Java, a linguagem, tem.
"a implementação de Closures em Groovy (e provavelmente no futuro J2SE7.0 Dolphin) são ainda mais poderosas que as do Lisp."
fico imaginando de que maneira uma implementação de captura de contextos léxicos possa ser notavelmente mais "poderosa" do que outra exatamente...
"Se vc. tiver o trabalho de ver a especificação do Generics vai perceber que, ao contrário, Java Generics é o "template dos ricos", contando com muito mais recursos do que o primeiro."
Ocorre em runtime, através de reflexão. Com C++ é durante a compilação, ou melhor, durante as transformações na AST...
"Vc. esqueceu de citar Java como plataforma que tem mecanismo de controle de namespace... :-P"
mas Java não é páreo para Ruby... :P
"É um conselho de muitas empresas, assim como ONGs, governos etc. Não há presidente, existe o poder de *voto*, não de *veto*."
e existe o poder de "sugestão", como a Sun exerce sobre Java... ;)
"O que falta é uma entidade que possua um *processo organizado, com regras bem definidas*. Isso é o que faz a diferença."
eu gosto do processo organizado do Linux: diffs e patches. :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
não me ponha nesse meio. e não confunda mediocridade com simplicidade.
"Closures não são o mesmo que classes anônimas"
é claro, mas é o mais próximo que Java, a linguagem, tem.
"a implementação de Closures em Groovy (e provavelmente no futuro J2SE7.0 Dolphin) são ainda mais poderosas que as do Lisp."
fico imaginando de que maneira uma implementação de captura de contextos léxicos possa ser notavelmente mais "poderosa" do que outra exatamente...
"Se vc. tiver o trabalho de ver a especificação do Generics vai perceber que, ao contrário, Java Generics é o "template dos ricos", contando com muito mais recursos do que o primeiro."
Ocorre em runtime, através de reflexão. Com C++ é durante a compilação, ou melhor, durante as transformações na AST...
"Vc. esqueceu de citar Java como plataforma que tem mecanismo de controle de namespace... :-P"
mas Java não é páreo para Ruby... :P
"É um conselho de muitas empresas, assim como ONGs, governos etc. Não há presidente, existe o poder de *voto*, não de *veto*."
e existe o poder de "sugestão", como a Sun exerce sobre Java... ;)
"O que falta é uma entidade que possua um *processo organizado, com regras bem definidas*. Isso é o que faz a diferença."
eu gosto do processo organizado do Linux: diffs e patches. :)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de anonymous
15/02/06 13:59
falta de conhecimento: >Integrar PHP com Java??? Meu Deus do céu: pra quê? A Oracle vai
>muito bem com Java obrigado, não precisa costurar essa traquizonga nele não...
dar-se-a entender q vc nuam entendeu o quis dizer ou naum conhece a historio do CF, em nenhum momento foi falado que o Oracle mudaria de java pra PHP e sim que que o CORE do PHP saria baseado em java, assim como eh hj com o CF. Interpretacao de texto eh bom. :)
>muito bem com Java obrigado, não precisa costurar essa traquizonga nele não...
dar-se-a entender q vc nuam entendeu o quis dizer ou naum conhece a historio do CF, em nenhum momento foi falado que o Oracle mudaria de java pra PHP e sim que que o CORE do PHP saria baseado em java, assim como eh hj com o CF. Interpretacao de texto eh bom. :)
Comentário de Copernico Vespucio
15/02/06 15:37 - usuário registrado #4868
RE: Rê: he: he: :-): "Closures não são o mesmo que classes anônimas"
é claro, mas é o mais próximo que Java, a linguagem, tem.
Então não se trata de "reinventar", certo? Agora sério: os objetivos de ambas as técnicas são bem diferentes. Classes Internas (Inner Classes), técnica na qual as classes anônimas se incluem entre outras três variações, existem a partir do Java 1.1 como uma melhor forma de organizar *fisicamente* o código. Em nenhum momento há a pretensão de imitar as closures. Internamente as closures são até mesmo implementadas com um mecanismo alternativo aos Stack Frames, ou seja, a implementação de destas em Java mexerá com a especificação da JVM.
Comparar classes internas anônimas com closures é como comparar abacaxi com pepinos.
fico imaginando de que maneira uma implementação de captura de contextos léxicos possa ser notavelmente mais "poderosa" do que outra exatamente...
Fica mais poderosa quando vc. a integra com a API java subjacente, como é feito em Groovy. Pesquise, estude, verifique.
Ocorre em runtime, através de reflexão. Com C++ é durante a compilação, ou melhor, durante as transformações na AST...
Incorreto, não é feito com reflexão, e sim com rótulos no bytecode e o uso inteligente de Erasure ("apagamento"), o que permite compatibilidade com JVMs sem Generics. Embora seja *possível* consultar as informações de tipos genericos em tempo de execução, com introspecção, a verificação de tipos propriamente dita ocorre apenas em tempo de compilação.
Entre outras diferenças. Leia mais.
mas Java não é páreo para Ruby... :P
E nem precisa ser. :-P
Controlar namespace para linguagens de script, totalmente interpretadas e dinâmicas, rodando sob ambiente inseguro, é *muito* mais complicado do que fazer isso em uma plataforma mais robusta.
e existe o poder de "sugestão", como a Sun exerce sobre Java... ;)
Sim, a Sun tem uma equipe de creolos (sic: termo de New Orleans) Vodu com os bonequinhos dos CEOs e lideres das entidades envolvidas... rs***
Sério: não há "sugestão" da Sun sobre o Java. Há "sugestão" vinda do mercado, que é muito mais poderosa.
eu gosto do processo organizado do Linux: diffs e patches. :)
Vc. está dizendo que todos os problemas organizacionais de uma plataforma são resolvidos apenas com packets, patches e diffs? PUTZ! Pelamordedeus, não vou nem responder a isso! kkkk! Vai correndo contar isso ao RMS, ele precisa do teu suporte para terminar o HUD.
[]s
é claro, mas é o mais próximo que Java, a linguagem, tem.
Então não se trata de "reinventar", certo? Agora sério: os objetivos de ambas as técnicas são bem diferentes. Classes Internas (Inner Classes), técnica na qual as classes anônimas se incluem entre outras três variações, existem a partir do Java 1.1 como uma melhor forma de organizar *fisicamente* o código. Em nenhum momento há a pretensão de imitar as closures. Internamente as closures são até mesmo implementadas com um mecanismo alternativo aos Stack Frames, ou seja, a implementação de destas em Java mexerá com a especificação da JVM.
Comparar classes internas anônimas com closures é como comparar abacaxi com pepinos.
fico imaginando de que maneira uma implementação de captura de contextos léxicos possa ser notavelmente mais "poderosa" do que outra exatamente...
Fica mais poderosa quando vc. a integra com a API java subjacente, como é feito em Groovy. Pesquise, estude, verifique.
Ocorre em runtime, através de reflexão. Com C++ é durante a compilação, ou melhor, durante as transformações na AST...
Incorreto, não é feito com reflexão, e sim com rótulos no bytecode e o uso inteligente de Erasure ("apagamento"), o que permite compatibilidade com JVMs sem Generics. Embora seja *possível* consultar as informações de tipos genericos em tempo de execução, com introspecção, a verificação de tipos propriamente dita ocorre apenas em tempo de compilação.
Entre outras diferenças. Leia mais.
mas Java não é páreo para Ruby... :P
E nem precisa ser. :-P
Controlar namespace para linguagens de script, totalmente interpretadas e dinâmicas, rodando sob ambiente inseguro, é *muito* mais complicado do que fazer isso em uma plataforma mais robusta.
e existe o poder de "sugestão", como a Sun exerce sobre Java... ;)
Sim, a Sun tem uma equipe de creolos (sic: termo de New Orleans) Vodu com os bonequinhos dos CEOs e lideres das entidades envolvidas... rs***
Sério: não há "sugestão" da Sun sobre o Java. Há "sugestão" vinda do mercado, que é muito mais poderosa.
eu gosto do processo organizado do Linux: diffs e patches. :)
Vc. está dizendo que todos os problemas organizacionais de uma plataforma são resolvidos apenas com packets, patches e diffs? PUTZ! Pelamordedeus, não vou nem responder a isso! kkkk! Vai correndo contar isso ao RMS, ele precisa do teu suporte para terminar o HUD.
[]s
Comentário de Copernico Vespucio
15/02/06 15:56 - usuário registrado #4868
"a vida não é filme e você não entendeu...": Creio que foi você que não entendeu, rapaz. Aquilo foi só uma piada e uma provocação inconsequente. Em resposta a declaração anterior.
Choques entre "tecnologias favoritas" dão origem a discussões sem fim (divertidas, e as vezes até produtivas, mas sem fim). Então se vc. me pegar fazendo uma declaração trollesca (é ruim pq é ruim) sobre alguma tecnologia, pode contar que é provocação.
Agora, teu teclado *naum* tem til não? Então usa ã no lugar! Pára com essa linguagem de "surfista digital", cara! :-P
Choques entre "tecnologias favoritas" dão origem a discussões sem fim (divertidas, e as vezes até produtivas, mas sem fim). Então se vc. me pegar fazendo uma declaração trollesca (é ruim pq é ruim) sobre alguma tecnologia, pode contar que é provocação.
Agora, teu teclado *naum* tem til não? Então usa ã no lugar! Pára com essa linguagem de "surfista digital", cara! :-P
Comentário de nemesis
16/02/06 7:58 - usuário registrado #1514
huhuuh: "Então não se trata de 'reinventar', certo?"
talvez eu tenha pego o exemplo errado: Java reinventou blocos do Smalltalk como classes anônimas... ;)
"Classes Internas ...existem ...como uma melhor forma de organizar *fisicamente* o código."
Eu estava falando de classes anônimas, não inner classes. Vc sabe, como quando vc precisa passar um callback, exceto que para Java tudo tem que ser uma instância de uma classe ou tipos simples, não podendo ser uma mera referência a um método. Então, inventaram anonymous classes para facilitar na definição de callbacks.
Então, digamos, em C++ vc tem
void Foo::fazAlgumaCoisa( int bar, int (*callback)(int) );
e pode chamá-lo assim:
foo->fazAlgumaCoisa( 2, &mycallback );
onde mycallback é um método ou função.
Em Java, não é possível definir parâmetros que são "ponteiros" para métodos: vc precisa especificar uma interface que tenha certos métodos, um dos quais é o que vc quer passar. Nuts!
Então, para aliviar um pouco a dor de ter que declarar uma classe que implemente os métodos e então chamá-la, vc pode usar uma sintaxe ligeiramente mais "trivial", como:
void fazAlgumaCoisa( int bar, CallbackSupplier cs );
sendo CallbackSupplier uma interface que pede implementação para int callback( int i );
e chamá-la:
void fazAlgumaCoisa( 2, new CallbackSupplier { public int callback( int i ) { return 2*i + 1; } } );
uau! realmente, pouco tem da praticidade ou beleza de closures ou blocos Smalltalk ( que no fim são a mesma coisa ), mas na prática, é sim uma clausura léxica, exceto que bastante verbosa e estúpida.
"Em nenhum momento há a pretensão de imitar as closures."
é o que há de mais parecido em Java. É verdade que, fora passagem de parâmetros para métodos, não há muito uso para elas, pois funções/métodos em Java não são dados como quaisquer outros ( higher order functions ): a mentalidade de Java é fazer tudo encapsulando em classes...
"Fica mais poderosa quando vc. a integra com a API java subjacente,"
E captura de contextos léxicos se beneficiaria disso porque...???
"Incorreto, não é feito com reflexão, e sim com rótulos no bytecode e ...a verificação de tipos propriamente dita ocorre apenas em tempo de compilação."
pena que em java tempo de compilação e tempo de execução sejam interrelacionados. :)
"Controlar namespace para linguagens de script, totalmente interpretadas e dinâmicas, rodando sob ambiente inseguro, é *muito* mais complicado do que fazer isso em uma plataforma mais robusta."
vc fala isso como se essas linguagens permitissem a um usuário qualquer entrando dados para programas escritos nessas linguagens arbitrariamente pudesse inserir código e executá-lo!
Se um programador faz eval de entradas de usuário, isso é um problema do programador, não da linguagem! Mesmo PHP realiza quotation de entradas para impedir programadores imbecis de atirarem no próprio pé arbitrariamente. eval é um comando bem útil nessas linguagens, mas deve ser usado em código em controle do programador.
Vc só está reclamando porque para fazer algo semelhante a eval( "1 + 2" ) em Java vc precisa usar linhas e mais linhas de reflexão, encapsulamento em classes e verbosidade apenas para começar alguma coisa...
robustez para vc é limitar o que o programador pode ou não pode fazer, certo?
"Sim, a Sun tem uma equipe de creolos (sic: termo de New Orleans) Vodu com os bonequinhos dos CEOs e lideres das entidades envolvidas... rs***"
eu já desconfiava... mas pensei que só o Bill usasse essa prática. E não o Joy! ;)
"Vc. está dizendo que todos os problemas organizacionais de uma plataforma são resolvidos apenas com packets, patches e diffs?...Vai correndo contar isso ao RMS, ele precisa do teu suporte para terminar o HUD."
conclusão: o Linux, com diffs e patches, funciona e evolui ao passo que o HURD é vaporware já há 20 anos...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
talvez eu tenha pego o exemplo errado: Java reinventou blocos do Smalltalk como classes anônimas... ;)
"Classes Internas ...existem ...como uma melhor forma de organizar *fisicamente* o código."
Eu estava falando de classes anônimas, não inner classes. Vc sabe, como quando vc precisa passar um callback, exceto que para Java tudo tem que ser uma instância de uma classe ou tipos simples, não podendo ser uma mera referência a um método. Então, inventaram anonymous classes para facilitar na definição de callbacks.
Então, digamos, em C++ vc tem
void Foo::fazAlgumaCoisa( int bar, int (*callback)(int) );
e pode chamá-lo assim:
foo->fazAlgumaCoisa( 2, &mycallback );
onde mycallback é um método ou função.
Em Java, não é possível definir parâmetros que são "ponteiros" para métodos: vc precisa especificar uma interface que tenha certos métodos, um dos quais é o que vc quer passar. Nuts!
Então, para aliviar um pouco a dor de ter que declarar uma classe que implemente os métodos e então chamá-la, vc pode usar uma sintaxe ligeiramente mais "trivial", como:
void fazAlgumaCoisa( int bar, CallbackSupplier cs );
sendo CallbackSupplier uma interface que pede implementação para int callback( int i );
e chamá-la:
void fazAlgumaCoisa( 2, new CallbackSupplier { public int callback( int i ) { return 2*i + 1; } } );
uau! realmente, pouco tem da praticidade ou beleza de closures ou blocos Smalltalk ( que no fim são a mesma coisa ), mas na prática, é sim uma clausura léxica, exceto que bastante verbosa e estúpida.
"Em nenhum momento há a pretensão de imitar as closures."
é o que há de mais parecido em Java. É verdade que, fora passagem de parâmetros para métodos, não há muito uso para elas, pois funções/métodos em Java não são dados como quaisquer outros ( higher order functions ): a mentalidade de Java é fazer tudo encapsulando em classes...
"Fica mais poderosa quando vc. a integra com a API java subjacente,"
E captura de contextos léxicos se beneficiaria disso porque...???
"Incorreto, não é feito com reflexão, e sim com rótulos no bytecode e ...a verificação de tipos propriamente dita ocorre apenas em tempo de compilação."
pena que em java tempo de compilação e tempo de execução sejam interrelacionados. :)
"Controlar namespace para linguagens de script, totalmente interpretadas e dinâmicas, rodando sob ambiente inseguro, é *muito* mais complicado do que fazer isso em uma plataforma mais robusta."
vc fala isso como se essas linguagens permitissem a um usuário qualquer entrando dados para programas escritos nessas linguagens arbitrariamente pudesse inserir código e executá-lo!
Se um programador faz eval de entradas de usuário, isso é um problema do programador, não da linguagem! Mesmo PHP realiza quotation de entradas para impedir programadores imbecis de atirarem no próprio pé arbitrariamente. eval é um comando bem útil nessas linguagens, mas deve ser usado em código em controle do programador.
Vc só está reclamando porque para fazer algo semelhante a eval( "1 + 2" ) em Java vc precisa usar linhas e mais linhas de reflexão, encapsulamento em classes e verbosidade apenas para começar alguma coisa...
robustez para vc é limitar o que o programador pode ou não pode fazer, certo?
"Sim, a Sun tem uma equipe de creolos (sic: termo de New Orleans) Vodu com os bonequinhos dos CEOs e lideres das entidades envolvidas... rs***"
eu já desconfiava... mas pensei que só o Bill usasse essa prática. E não o Joy! ;)
"Vc. está dizendo que todos os problemas organizacionais de uma plataforma são resolvidos apenas com packets, patches e diffs?...Vai correndo contar isso ao RMS, ele precisa do teu suporte para terminar o HUD."
conclusão: o Linux, com diffs e patches, funciona e evolui ao passo que o HURD é vaporware já há 20 anos...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Copernico Vespucio
16/02/06 12:53 - usuário registrado #4868
huhuuh = desinformação: Ok, vamos dar início à nossa aula! ;-P
talvez eu tenha pego o exemplo errado: Java reinventou blocos do Smalltalk como classes anônimas... ;)
Mais uma vez, bola fora. Os blocos (Stack Frames) do Java são sim, baseados no Smalltalk e ninguém nega isso. Não é "reinvenção". É uso. Mas isso não tem NADA a ver com classes anônimas. Tá te faltando conhecimento pra prosseguir na discussão, Nêmesis.
"Eu estava falando de classes anônimas, não inner classes."
Como eu já disse antes, classe anônima é uma das 4 formas de classes internas, que têm as mesmas propriedades e são compiladas da mesma forma. Então, se vc. está falando de classe anônima, está falando de Inner Class. Esclarecendo um pouco mais, classes anônimas podem se usadas para um simples callback, mas não se limitam a isso. Lembre-se que vc. não pode usar todo o poder de herança com uma closure (ou como um ponteiro de método em C++), mas pode fazê-lo com inner classes. A propósito não precisava escrever esse código todo, eu entenderia o que vc. quis dizer mesmo assim.
a mentalidade de Java é fazer tudo encapsulando em classes...
Exatamente. "Imaginação Pequena" como se diz em Wing Chun. Tudo é classe. Mesmo os diversos tipos de açúcar sintático (inner class, enum, annotations e, futuramente, os closures) são compilados como classes. Isso permite que o modelo de linguagem e JVM não tenha regras particulares para cada construto, simplificando os modelos de segurança e memória e facilitando a vida do programador: se algo é feito em Java, há uma classe que faz isso.
E captura de contextos léxicos se beneficiaria disso porque...???
http://groovy.codehaus.org/Tutorial+2+-+Code+as+data%2C+or+closures?nocache
Observe o uso de each() e collect() nas closures e representações nativas de coleção, por exemplo. Saiba que esses métodos fazem parte da API do Groovy (uma biblioteca Java como outra qualquer), será compilado como classes que poderão inclusive ser usadas em algum projeto não groovy.
Vc. pode definir métodos Java comuns que poderão ser usados sobre uma closure de forma similar.
pena que em java tempo de compilação e tempo de execução sejam interrelacionados. :)
Essa é uma daquelas frases que parecem extremamente inteligentes a princípio mas na verdade são bastante estúpidas... :-/
Não, não estão mais relacionados que em qualquer outra linguagem. Tempo de compilação é tempo de compilação e runtime é runtime. Tá faltando conhecimento de novo.
vc fala isso como se essas linguagens permitissem a um usuário qualquer entrando dados para programas escritos nessas linguagens arbitrariamente pudesse inserir código e executá-lo!
. . .
Se um programador faz eval de entradas de usuário, isso é um problema do programador, não da linguagem!
Essa é um exemplo de falha de segurança, mas é muito óbvio e grosseirao para entrar na discussão. Existem outros recursos de invasão, do tipo adicionar um método dinamicamente a uma classe, sendo que seria elegível para que o polimorfismo invoque esse método ao invés do original. Por exemplo:
Método original em sua biblioteca de classe:
public void metodo(CharSequence chs){ . . . }
Um programador malandro troca ou insere uma classe no seu pacote de forma a invocar se programa adicionando dinamicamente o seguinte método seu:
public void metodo(String s){ /* faz o que quiser, é tudo da lei */ }
Bem, a maior parte das chamadas de método passam String ao método original. Como toda String é uma CharSequence tb, o método escolhido será o mais específico, em detrimento do mais abrangente. O método substituto será executado toda vez que o original for chamado. A partir desse expediente vc. poderia crackear um software, ou até mesmo acessar informações que não deveria (exemplo bem besta? Logar todas as strings passadas). É por isso que não se pode adicionar métodos dinamicamente em Java.
No caso do eval(), lembre-se que as Strings com seu código a executar estarão na memória. Na área do heap para VMs, ou em uma tabela de Strings, em outras plataformas. Basta que um atacante tenha acesso de escrita à área de memória onde isso está para mudar radicalmente o comportamento do código. Para implementações de VM mal feitas, ou mais facilmente para plataformas nativas, um simples estouro de pilha permitiria isso. Essas coisas são bem mais sutiis do que esse ataque ingênuo que vc. citou, e em línguas muito dinâmicas isso é bem mais difícil de controlar.
robustez para vc é limitar o que o programador pode ou não pode fazer, certo?
Não é, mas faz parte. Prazos curtos não podem obrigar a um programador a comprometer a plataforma com excesso de "truques sujos", pegadinhas e regras particulares. Como bônus, vc. ganha um código mais legível. Robustez fala de uma forma bem definida e exclusiva de fazer as coisas.
conclusão: o Linux, com diffs e patches, funciona e evolui ao passo que o HURD é vaporware já há 20 anos...
O Linux funciona graças a um sistema organizado de controle centrado nos mantenedores do Kernel regionais, que estão em contato direto como Linus, impede que um zé-ruela qualquer meta as patas sujas no kernel.
Não precisa ser tão elaborado quanto o JCP pq não tem a pressão de ser democrático. É uma "elite" (panela) que decide os rumos que o Kernel vai tomar. Com ele funcionando, o resto do mundo pode fazer o que quiser em torno dele (e assumir sozinhos as consequencias disso), sem estragar o sistema.
Não vamos tornar essa discussão muito longa, ok? Está meio fora do tópico, tem potencial para encher o saco dos leitores e está se encaminhando de novo ao "limite vertical". Se tem algo a contestar, seja claro, sem trollagem, e objetivo.
talvez eu tenha pego o exemplo errado: Java reinventou blocos do Smalltalk como classes anônimas... ;)
Mais uma vez, bola fora. Os blocos (Stack Frames) do Java são sim, baseados no Smalltalk e ninguém nega isso. Não é "reinvenção". É uso. Mas isso não tem NADA a ver com classes anônimas. Tá te faltando conhecimento pra prosseguir na discussão, Nêmesis.
"Eu estava falando de classes anônimas, não inner classes."
Como eu já disse antes, classe anônima é uma das 4 formas de classes internas, que têm as mesmas propriedades e são compiladas da mesma forma. Então, se vc. está falando de classe anônima, está falando de Inner Class. Esclarecendo um pouco mais, classes anônimas podem se usadas para um simples callback, mas não se limitam a isso. Lembre-se que vc. não pode usar todo o poder de herança com uma closure (ou como um ponteiro de método em C++), mas pode fazê-lo com inner classes. A propósito não precisava escrever esse código todo, eu entenderia o que vc. quis dizer mesmo assim.
a mentalidade de Java é fazer tudo encapsulando em classes...
Exatamente. "Imaginação Pequena" como se diz em Wing Chun. Tudo é classe. Mesmo os diversos tipos de açúcar sintático (inner class, enum, annotations e, futuramente, os closures) são compilados como classes. Isso permite que o modelo de linguagem e JVM não tenha regras particulares para cada construto, simplificando os modelos de segurança e memória e facilitando a vida do programador: se algo é feito em Java, há uma classe que faz isso.
E captura de contextos léxicos se beneficiaria disso porque...???
http://groovy.codehaus.org/Tutorial+2+-+Code+as+data%2C+or+closures?nocache
Observe o uso de each() e collect() nas closures e representações nativas de coleção, por exemplo. Saiba que esses métodos fazem parte da API do Groovy (uma biblioteca Java como outra qualquer), será compilado como classes que poderão inclusive ser usadas em algum projeto não groovy.
Vc. pode definir métodos Java comuns que poderão ser usados sobre uma closure de forma similar.
pena que em java tempo de compilação e tempo de execução sejam interrelacionados. :)
Essa é uma daquelas frases que parecem extremamente inteligentes a princípio mas na verdade são bastante estúpidas... :-/
Não, não estão mais relacionados que em qualquer outra linguagem. Tempo de compilação é tempo de compilação e runtime é runtime. Tá faltando conhecimento de novo.
vc fala isso como se essas linguagens permitissem a um usuário qualquer entrando dados para programas escritos nessas linguagens arbitrariamente pudesse inserir código e executá-lo!
. . .
Se um programador faz eval de entradas de usuário, isso é um problema do programador, não da linguagem!
Essa é um exemplo de falha de segurança, mas é muito óbvio e grosseirao para entrar na discussão. Existem outros recursos de invasão, do tipo adicionar um método dinamicamente a uma classe, sendo que seria elegível para que o polimorfismo invoque esse método ao invés do original. Por exemplo:
Método original em sua biblioteca de classe:
public void metodo(CharSequence chs){ . . . }
Um programador malandro troca ou insere uma classe no seu pacote de forma a invocar se programa adicionando dinamicamente o seguinte método seu:
public void metodo(String s){ /* faz o que quiser, é tudo da lei */ }
Bem, a maior parte das chamadas de método passam String ao método original. Como toda String é uma CharSequence tb, o método escolhido será o mais específico, em detrimento do mais abrangente. O método substituto será executado toda vez que o original for chamado. A partir desse expediente vc. poderia crackear um software, ou até mesmo acessar informações que não deveria (exemplo bem besta? Logar todas as strings passadas). É por isso que não se pode adicionar métodos dinamicamente em Java.
No caso do eval(), lembre-se que as Strings com seu código a executar estarão na memória. Na área do heap para VMs, ou em uma tabela de Strings, em outras plataformas. Basta que um atacante tenha acesso de escrita à área de memória onde isso está para mudar radicalmente o comportamento do código. Para implementações de VM mal feitas, ou mais facilmente para plataformas nativas, um simples estouro de pilha permitiria isso. Essas coisas são bem mais sutiis do que esse ataque ingênuo que vc. citou, e em línguas muito dinâmicas isso é bem mais difícil de controlar.
robustez para vc é limitar o que o programador pode ou não pode fazer, certo?
Não é, mas faz parte. Prazos curtos não podem obrigar a um programador a comprometer a plataforma com excesso de "truques sujos", pegadinhas e regras particulares. Como bônus, vc. ganha um código mais legível. Robustez fala de uma forma bem definida e exclusiva de fazer as coisas.
conclusão: o Linux, com diffs e patches, funciona e evolui ao passo que o HURD é vaporware já há 20 anos...
O Linux funciona graças a um sistema organizado de controle centrado nos mantenedores do Kernel regionais, que estão em contato direto como Linus, impede que um zé-ruela qualquer meta as patas sujas no kernel.
Não precisa ser tão elaborado quanto o JCP pq não tem a pressão de ser democrático. É uma "elite" (panela) que decide os rumos que o Kernel vai tomar. Com ele funcionando, o resto do mundo pode fazer o que quiser em torno dele (e assumir sozinhos as consequencias disso), sem estragar o sistema.
Não vamos tornar essa discussão muito longa, ok? Está meio fora do tópico, tem potencial para encher o saco dos leitores e está se encaminhando de novo ao "limite vertical". Se tem algo a contestar, seja claro, sem trollagem, e objetivo.
Comentário de nemesis
16/02/06 16:05 - usuário registrado #1514
tá faltando conhecimento!: "Os blocos (Stack Frames) do Java são sim, baseados no Smalltalk e ninguém nega isso. Não é 'reinvenção'. É uso."
Doh! é uso interno, na implementação, não acessível ao programador...
"Mas isso não tem NADA a ver com classes anônimas."
tem razão. foi uma comparação errônea, apenas a título de boa fé para com Java. ;)
"Como eu já disse antes, classe anônima é uma das 4 formas de classes internas,"
mas é a anônima que mais se aproxima do conceito de closure ou dos blocos smalltalk.
"Então, se vc. está falando de classe anônima, está falando de Inner Class."
Toda classe anônima é uma inner class, mas o contrário não é verdade. Por isso, quando estou falando de closure e comparando com classes anônimas, não posso levar a comparação adiante para toda inner class...
"vc. não pode usar todo o poder de herança com uma closure (ou como um ponteiro de método em C++), mas pode fazê-lo com inner classes."
seria esse poder de herança simplesmente despachar a função certa para a o processamento de algum dado passado como parâmetro? ( passado implicitamente pelos compiladores Java/C++ na forma do "global" this )
Uma closure é uma função anônima com contexto léxico associado. Não entendo pq herança seria de alguma utilidade...
"eu entenderia o que vc. quis dizer mesmo assim."
lamento por ter subestimado sua inteligência.
"Tudo é classe."
exceto, infelizmente, os tipos básicos, que têm ridículas classes wrapper para certas ocasiões. Bem diferente de Smalltalk ou Ruby e sua completa e consistente orientação-a-objetos.
"Mesmo os diversos tipos de açúcar sintático (inner class, enum, annotations e, futuramente, os closures) são compilados como classes."
"se algo é feito em Java, há uma classe que faz isso."
passar callbacks dessa forma é realmente estúpido. Me pergunto porque não pelo menos algo como um Functor...
"http://groovy.codehaus.org/Tutorial+2+-+Code+as+data%2C+or+closures?nocache"
O link acima dá uma visão geral sobre closures, desnecessária. E não responde de que maneira closures se beneficiariam de herança ou API java...
"Observe o uso de each() e collect() nas closures e representações nativas de coleção, por exemplo. Saiba que esses métodos fazem parte da API do Groovy (uma biblioteca Java como outra qualquer),"
e o que exatamente esses métodos "externos" à closure ( que é uma "função" ) têm a ver com closures ou de que forma às beneficiariam?
Sabe que o método collect de objetos colection simplesmente "aplica" a closure ( uma entidade em separado ) a cada um de seus elementos e retorna uma lista com o resultado da aplicação da função anônima aos seus elementos. É a popular função map de linguagens funcionais. E nada tem a ver com closures: pode aplicar funções nomeadas tmb...
"Vc. pode definir métodos Java comuns que poderão ser usados sobre uma closure de forma similar."
Não. Métodos que vão "aplicar" ( ou usar ) a closure. Vc tenta passar a impressão de que closures estão se beneficiando dos métodos, quando é o contrário.
"Tempo de compilação é tempo de compilação e runtime é runtime."
É que geralmente não espero meus programas C/C++ compilarem quando clico em seus ícones. ;)
"Existem outros recursos de invasão, do tipo adicionar um método dinamicamente a uma classe, sendo que seria elegível para que o polimorfismo invoque esse método ao invés do original..."
programadores malandros existem em java também, mas como a linguagem foi projetada para ser limitada, eles têm mais dificuldade em realizar coisas. em tudo, claro...
"No caso do eval(), lembre-se que as Strings com seu código a executar estarão na memória. Na área do heap para VMs, ou em uma tabela de Strings, em outras plataformas. Basta que um atacante tenha acesso de escrita à área de memória onde isso está para mudar radicalmente o comportamento do código."
oh, infelizmente parece ser um problema para Java também se essa string contiver código para acessar a API de reflexão. Talvez a avançada VM seja capaz de lidar com isso melhor que a de Python ou Ruby, mas isso não é um problema com a linguagem, mas com a implementação. O fato é: existe "eval" em Java, apenas que o mesmo é acessível apenas através de centenas de linhas de chamadas reflexivas...
"Prazos curtos não podem obrigar a um programador a comprometer a plataforma com excesso de 'truques sujos', pegadinhas e regras particulares."
o pessoal de java me lembra aquele pessoal medieval que adorava se auto-inflingir torturas... :)
"Como bônus, vc. ganha um código mais legível."
em 10000+ linhas de verboso código!
"O Linux funciona graças a um sistema organizado de controle centrado nos mantenedores do Kernel regionais, que estão em contato direto como Linus, impede que um zé-ruela qualquer meta as patas sujas no kernel."
qualquer um, a qualquer momento, pode submeter um diff e eles decidem aplicá-lo ou não.
"Não precisa ser tão elaborado quanto o JCP pq não tem a pressão de ser democrático."
ou burocrático. Tem que admitir que o modelo de ditatores benevolentes encontrado em muitos projetos de software livre parece fluir mais rápido -- Linux, Python, Ruby etc...
"Não vamos tornar essa discussão muito longa, ok? Está meio fora do tópico, tem potencial para encher o saco dos leitores"
essa thread já é velha. só nós ainda estamos lendo... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Doh! é uso interno, na implementação, não acessível ao programador...
"Mas isso não tem NADA a ver com classes anônimas."
tem razão. foi uma comparação errônea, apenas a título de boa fé para com Java. ;)
"Como eu já disse antes, classe anônima é uma das 4 formas de classes internas,"
mas é a anônima que mais se aproxima do conceito de closure ou dos blocos smalltalk.
"Então, se vc. está falando de classe anônima, está falando de Inner Class."
Toda classe anônima é uma inner class, mas o contrário não é verdade. Por isso, quando estou falando de closure e comparando com classes anônimas, não posso levar a comparação adiante para toda inner class...
"vc. não pode usar todo o poder de herança com uma closure (ou como um ponteiro de método em C++), mas pode fazê-lo com inner classes."
seria esse poder de herança simplesmente despachar a função certa para a o processamento de algum dado passado como parâmetro? ( passado implicitamente pelos compiladores Java/C++ na forma do "global" this )
Uma closure é uma função anônima com contexto léxico associado. Não entendo pq herança seria de alguma utilidade...
"eu entenderia o que vc. quis dizer mesmo assim."
lamento por ter subestimado sua inteligência.
"Tudo é classe."
exceto, infelizmente, os tipos básicos, que têm ridículas classes wrapper para certas ocasiões. Bem diferente de Smalltalk ou Ruby e sua completa e consistente orientação-a-objetos.
"Mesmo os diversos tipos de açúcar sintático (inner class, enum, annotations e, futuramente, os closures) são compilados como classes."
"se algo é feito em Java, há uma classe que faz isso."
passar callbacks dessa forma é realmente estúpido. Me pergunto porque não pelo menos algo como um Functor...
"http://groovy.codehaus.org/Tutorial+2+-+Code+as+data%2C+or+closures?nocache"
O link acima dá uma visão geral sobre closures, desnecessária. E não responde de que maneira closures se beneficiariam de herança ou API java...
"Observe o uso de each() e collect() nas closures e representações nativas de coleção, por exemplo. Saiba que esses métodos fazem parte da API do Groovy (uma biblioteca Java como outra qualquer),"
e o que exatamente esses métodos "externos" à closure ( que é uma "função" ) têm a ver com closures ou de que forma às beneficiariam?
Sabe que o método collect de objetos colection simplesmente "aplica" a closure ( uma entidade em separado ) a cada um de seus elementos e retorna uma lista com o resultado da aplicação da função anônima aos seus elementos. É a popular função map de linguagens funcionais. E nada tem a ver com closures: pode aplicar funções nomeadas tmb...
"Vc. pode definir métodos Java comuns que poderão ser usados sobre uma closure de forma similar."
Não. Métodos que vão "aplicar" ( ou usar ) a closure. Vc tenta passar a impressão de que closures estão se beneficiando dos métodos, quando é o contrário.
"Tempo de compilação é tempo de compilação e runtime é runtime."
É que geralmente não espero meus programas C/C++ compilarem quando clico em seus ícones. ;)
"Existem outros recursos de invasão, do tipo adicionar um método dinamicamente a uma classe, sendo que seria elegível para que o polimorfismo invoque esse método ao invés do original..."
programadores malandros existem em java também, mas como a linguagem foi projetada para ser limitada, eles têm mais dificuldade em realizar coisas. em tudo, claro...
"No caso do eval(), lembre-se que as Strings com seu código a executar estarão na memória. Na área do heap para VMs, ou em uma tabela de Strings, em outras plataformas. Basta que um atacante tenha acesso de escrita à área de memória onde isso está para mudar radicalmente o comportamento do código."
oh, infelizmente parece ser um problema para Java também se essa string contiver código para acessar a API de reflexão. Talvez a avançada VM seja capaz de lidar com isso melhor que a de Python ou Ruby, mas isso não é um problema com a linguagem, mas com a implementação. O fato é: existe "eval" em Java, apenas que o mesmo é acessível apenas através de centenas de linhas de chamadas reflexivas...
"Prazos curtos não podem obrigar a um programador a comprometer a plataforma com excesso de 'truques sujos', pegadinhas e regras particulares."
o pessoal de java me lembra aquele pessoal medieval que adorava se auto-inflingir torturas... :)
"Como bônus, vc. ganha um código mais legível."
em 10000+ linhas de verboso código!
"O Linux funciona graças a um sistema organizado de controle centrado nos mantenedores do Kernel regionais, que estão em contato direto como Linus, impede que um zé-ruela qualquer meta as patas sujas no kernel."
qualquer um, a qualquer momento, pode submeter um diff e eles decidem aplicá-lo ou não.
"Não precisa ser tão elaborado quanto o JCP pq não tem a pressão de ser democrático."
ou burocrático. Tem que admitir que o modelo de ditatores benevolentes encontrado em muitos projetos de software livre parece fluir mais rápido -- Linux, Python, Ruby etc...
"Não vamos tornar essa discussão muito longa, ok? Está meio fora do tópico, tem potencial para encher o saco dos leitores"
essa thread já é velha. só nós ainda estamos lendo... ;)
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Copernico Vespucio
16/02/06 17:39 - usuário registrado #4868
tá mesmo!: quando estou falando de closure e comparando com classes anônimas, não posso levar a comparação adiante para toda inner class...
Pode! kkkkk! Todas as características de uma classe anônima são compartilhadas pelos outros tipos de Inner Classes (enxergar variáveis finais no contexto da classe externa, associação de dependência, etc). A *única diferença que uma classe anônima tem das outras inner classes é que, bem... a classe anônima não tem nome... ;-)
seria esse poder de herança simplesmente despachar a função certa para a o processamento de algum dado passado como parâmetro?
. . .
Não entendo pq herança seria de alguma utilidade...
Não. E é de muita utilidade. Crie uma classe anônima cuja superclasse realize algum processamento no construtor. Crie um objeto dessa classe e vc. acaba de aproveitar o código de inicialização da superclasse sem ter de duplicá-lo. Os métodos da classe anônima poderão acessar atributos e métodos não-privados de sua superclasse, assim como qualquer variável ou método final da classe externa onde a classe anônima foi declarada (ou métodos e atributos não-privados e finais de qualquer superclasse desta).
Nos exemplinhos iniciantes de callback para interfaces gráficas que abundam por aí, criam-se classes anônimas que implementam ActionEvent e fazem disso apenas um callback. Eu faço o mesmo, mas extendendo javax.swing.AbstractAction. Com isso obtenho, além do callback, um objeto ação contendo nome, ícone, teclas de atalho, etc. Pronto para ser atribuído a itens de menu e barras de ferramenta, com mínima codificação.
exceto, infelizmente, os tipos básicos, que têm ridículas classes wrapper para certas ocasiões.
Seus conhecimentos estão desatualizados. tipos primitivos (apenas 8) são agora *automaticamente* convertidos para objetos wrapper correspondentes quando necessário. Isso se chama autoboxing/autounboxing. Um exemplo:
//Um número inteiro se tornando um objeto:
Integer numero = 13;
A diferença do Smalltalk é agora que os tipos não são armazenados como objetos a menos que se precise disso. O que faz *muita* diferença na performance e no footprint. Essa é uma das razões para o Smalltalk não ter se tornado popular (tudo é objeto, gasta-se heap pra caramba).
É que geralmente não espero meus programas C/C++ compilarem quando clico em seus ícones.
Vc. talvez esteja confundindo a pré-compilação para bytecode com a compilação para código nativo realizada pelo JIT. Durante o runtime o JIT do Java pode compilar "hot spots" de um bytecode para código nativo aplicando otimizações, mas nesse ponto coisas como generics já terão sido resolvidas pelo pré-compilador. JIT não tem nada mais a ver com generics, nem com enum, ou qualquer outro açúcar sintático.
O fato é: existe "eval" em Java, apenas que o mesmo é acessível apenas através de centenas de linhas de chamadas reflexivas...
Existem regras para chamadas reflexivas também. Além disso, até para usar chamadas reflexivas vc. precisa de permissão do SecurityManager para as classes que deseja. Em ambientes mais seguros, como servidores de aplicação, por exemplo, pode ser vetada a reflexão sobre as core classes do Java ou sobre as classes que fazem parte da implementação do servidor. Isso não é problema para Java não, não se preocupe.
em 10000+ linhas de verboso código!
Menos, bem menos...
Ao menos quando eu termino de ler um código Java, ainda que longo, eu o compreendi. Ao invés de ficar horas olhando apenas umas duas dúzias de linhas, tentando imaginar o que o excomungado do autor queria fazer com aquela teia de aranha (trechos com várias sobrecargas de operador sem sentido, utilizadas em closures dentro de closures)... Insanidade expressa em poucas linhas (escreveu rápido, achou que era esperto, mas o resultado final é um hieróglifo). O mesmo vale para ponteiros de funções no C++ e até mesmo seus templates.
o pessoal de java me lembra aquele pessoal medieval que adorava se auto-inflingir torturas... :)
Não é tortura, e sim se ater às regras. Esse pequeno esforço é largamente recompensado quando eu não preciso gastar minha noite toda depurando meu código (ou pior, algum código "místico" escrito por algum "gênio") e posso dormir com a minha namorada ao invés disso.
Tem que admitir que o modelo de ditatores benevolentes encontrado em muitos projetos de software livre parece fluir mais rápido -- Linux, Python, Ruby etc...
O chato é que os "ditadores benevolentes" acabam tendo muito mais trabalho do que deveriam ter. Pois precisam validar *tudo*.
Bem, você poderia considerar a Sun ou o Apache Group como os "ditadores benevolentes" do Java, mas a própria comunidade SL não acha isso suficiente. Quando é ditatorial, reclama. Quando é democrático, reclama. :-<
essa thread já é velha. só nós ainda estamos lendo... ;)
Se vc. assume a responsabilidade, então manda bala. Mas aviso que eu vou parar quando cada linha só couber duas palavras. Dá claustrofobia :-P
Pode! kkkkk! Todas as características de uma classe anônima são compartilhadas pelos outros tipos de Inner Classes (enxergar variáveis finais no contexto da classe externa, associação de dependência, etc). A *única diferença que uma classe anônima tem das outras inner classes é que, bem... a classe anônima não tem nome... ;-)
seria esse poder de herança simplesmente despachar a função certa para a o processamento de algum dado passado como parâmetro?
. . .
Não entendo pq herança seria de alguma utilidade...
Não. E é de muita utilidade. Crie uma classe anônima cuja superclasse realize algum processamento no construtor. Crie um objeto dessa classe e vc. acaba de aproveitar o código de inicialização da superclasse sem ter de duplicá-lo. Os métodos da classe anônima poderão acessar atributos e métodos não-privados de sua superclasse, assim como qualquer variável ou método final da classe externa onde a classe anônima foi declarada (ou métodos e atributos não-privados e finais de qualquer superclasse desta).
Nos exemplinhos iniciantes de callback para interfaces gráficas que abundam por aí, criam-se classes anônimas que implementam ActionEvent e fazem disso apenas um callback. Eu faço o mesmo, mas extendendo javax.swing.AbstractAction. Com isso obtenho, além do callback, um objeto ação contendo nome, ícone, teclas de atalho, etc. Pronto para ser atribuído a itens de menu e barras de ferramenta, com mínima codificação.
exceto, infelizmente, os tipos básicos, que têm ridículas classes wrapper para certas ocasiões.
Seus conhecimentos estão desatualizados. tipos primitivos (apenas 8) são agora *automaticamente* convertidos para objetos wrapper correspondentes quando necessário. Isso se chama autoboxing/autounboxing. Um exemplo:
//Um número inteiro se tornando um objeto:
Integer numero = 13;
A diferença do Smalltalk é agora que os tipos não são armazenados como objetos a menos que se precise disso. O que faz *muita* diferença na performance e no footprint. Essa é uma das razões para o Smalltalk não ter se tornado popular (tudo é objeto, gasta-se heap pra caramba).
É que geralmente não espero meus programas C/C++ compilarem quando clico em seus ícones.
Vc. talvez esteja confundindo a pré-compilação para bytecode com a compilação para código nativo realizada pelo JIT. Durante o runtime o JIT do Java pode compilar "hot spots" de um bytecode para código nativo aplicando otimizações, mas nesse ponto coisas como generics já terão sido resolvidas pelo pré-compilador. JIT não tem nada mais a ver com generics, nem com enum, ou qualquer outro açúcar sintático.
O fato é: existe "eval" em Java, apenas que o mesmo é acessível apenas através de centenas de linhas de chamadas reflexivas...
Existem regras para chamadas reflexivas também. Além disso, até para usar chamadas reflexivas vc. precisa de permissão do SecurityManager para as classes que deseja. Em ambientes mais seguros, como servidores de aplicação, por exemplo, pode ser vetada a reflexão sobre as core classes do Java ou sobre as classes que fazem parte da implementação do servidor. Isso não é problema para Java não, não se preocupe.
em 10000+ linhas de verboso código!
Menos, bem menos...
Ao menos quando eu termino de ler um código Java, ainda que longo, eu o compreendi. Ao invés de ficar horas olhando apenas umas duas dúzias de linhas, tentando imaginar o que o excomungado do autor queria fazer com aquela teia de aranha (trechos com várias sobrecargas de operador sem sentido, utilizadas em closures dentro de closures)... Insanidade expressa em poucas linhas (escreveu rápido, achou que era esperto, mas o resultado final é um hieróglifo). O mesmo vale para ponteiros de funções no C++ e até mesmo seus templates.
o pessoal de java me lembra aquele pessoal medieval que adorava se auto-inflingir torturas... :)
Não é tortura, e sim se ater às regras. Esse pequeno esforço é largamente recompensado quando eu não preciso gastar minha noite toda depurando meu código (ou pior, algum código "místico" escrito por algum "gênio") e posso dormir com a minha namorada ao invés disso.
Tem que admitir que o modelo de ditatores benevolentes encontrado em muitos projetos de software livre parece fluir mais rápido -- Linux, Python, Ruby etc...
O chato é que os "ditadores benevolentes" acabam tendo muito mais trabalho do que deveriam ter. Pois precisam validar *tudo*.
Bem, você poderia considerar a Sun ou o Apache Group como os "ditadores benevolentes" do Java, mas a própria comunidade SL não acha isso suficiente. Quando é ditatorial, reclama. Quando é democrático, reclama. :-<
essa thread já é velha. só nós ainda estamos lendo... ;)
Se vc. assume a responsabilidade, então manda bala. Mas aviso que eu vou parar quando cada linha só couber duas palavras. Dá claustrofobia :-P
Comentário de nemesis
16/02/06 21:58 - usuário registrado #1514
legal!: "Pode!"
não, não pode.
"A única diferença que uma classe anônima tem das outras inner classes é que, bem... a classe anônima não tem nome... ;-)"
E é por isso que não pode: uma closure por definição *é* uma função anônima com ambiente léxico estático associado em sua definição. Uma função em qualquer linguagem de programação razoavelmente moderna já tem por si própria escopo léxico estático -- um conceito surgido nos anos 70.
Para dar suporte a closures, uma linguagem precisa tratar funções como outro tipo de dado qualquer, podendo passá-lo livremente por parâmetro e retornar novas closures a partir de funções. Java não permite nem um nem outro, pois métodos não são objetos e a linguagem só trata objetos.
"Não. E é de muita utilidade."
Que seja. Passando um objeto explicitamente para uma função, ela pode chamar o "método" adequado para aquele objeto dependendo de seu tipo. Presto, "herança"! Possível em qualquer linguagem, mas particularmente em linguagens dinamicamente tipadas, se precisar...
"Eu faço o mesmo, mas extendendo javax.swing.AbstractAction. Com isso obtenho, além do callback, um objeto ação contendo nome, ícone, teclas de atalho, etc."
semelhante a void exec( void (*callback)( AbstractActionStruct *act ), AbstractActionStruct *act )?
hmm, acho que estamos divagando...
"tipos primitivos (apenas 8) são agora *automaticamente* convertidos para objetos wrapper correspondentes quando necessário. Isso se chama autoboxing/autounboxing."
ah! parece que afinal C# e seu sistema de tipos unificado agitou as coisas no mundo Java...
"A diferença do Smalltalk é agora que os tipos não são armazenados como objetos a menos que se precise disso."
confesso que é uma boa. mais memória do que Java já usa...
"Durante o runtime o JIT do Java pode compilar 'hot spots' de um bytecode para código nativo aplicando otimizações, mas nesse ponto coisas como generics já terão sido resolvidas pelo pré-compilador."
não importa. fiz vc admitir que a compilação ocorre em tempo de execução. ;)
"até para usar chamadas reflexivas vc. precisa de permissão do SecurityManager"
é, nosso "SecurityManager" tmb não gosta muito de eval e nos limita tanto quanto o do Java. Estamos pensando em substituí-lo ou gerar um core dump... ;)
"Ao menos quando eu termino de ler um código Java, ainda que longo, eu o compreendi. Ao invés de ficar horas olhando..."
Algumas pessoas gostam de programar no nível de domínio atual e por isso criam sub linguagens específicas de domínio em cima da própria linguagem de programação e programam nessa abstração mais alta e mais próxima da realidade da aplicação, ao invés de ficar tentando agradar ao compilador com declarações redundantes ou mecanismos de controle arcaicos.
Ou talvez vc estivesse falando de script-kiddies?...
"eu não preciso gastar minha noite toda depurando meu código..."
Mas há aqueles "momentos" com ela em que vc preferiria ficar depurando COBOL às 4 da manhã! :)))
"os 'ditadores benevolentes' acabam tendo muito mais trabalho...Pois precisam validar *tudo*."
eles podem sempre delegar... ;)
"aviso que eu vou parar quando cada linha só couber duas palavras."
já posso adiantar minha 2 palavras finais: Java sucks!! :)))
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
não, não pode.
"A única diferença que uma classe anônima tem das outras inner classes é que, bem... a classe anônima não tem nome... ;-)"
E é por isso que não pode: uma closure por definição *é* uma função anônima com ambiente léxico estático associado em sua definição. Uma função em qualquer linguagem de programação razoavelmente moderna já tem por si própria escopo léxico estático -- um conceito surgido nos anos 70.
Para dar suporte a closures, uma linguagem precisa tratar funções como outro tipo de dado qualquer, podendo passá-lo livremente por parâmetro e retornar novas closures a partir de funções. Java não permite nem um nem outro, pois métodos não são objetos e a linguagem só trata objetos.
"Não. E é de muita utilidade."
Que seja. Passando um objeto explicitamente para uma função, ela pode chamar o "método" adequado para aquele objeto dependendo de seu tipo. Presto, "herança"! Possível em qualquer linguagem, mas particularmente em linguagens dinamicamente tipadas, se precisar...
"Eu faço o mesmo, mas extendendo javax.swing.AbstractAction. Com isso obtenho, além do callback, um objeto ação contendo nome, ícone, teclas de atalho, etc."
semelhante a void exec( void (*callback)( AbstractActionStruct *act ), AbstractActionStruct *act )?
hmm, acho que estamos divagando...
"tipos primitivos (apenas 8) são agora *automaticamente* convertidos para objetos wrapper correspondentes quando necessário. Isso se chama autoboxing/autounboxing."
ah! parece que afinal C# e seu sistema de tipos unificado agitou as coisas no mundo Java...
"A diferença do Smalltalk é agora que os tipos não são armazenados como objetos a menos que se precise disso."
confesso que é uma boa. mais memória do que Java já usa...
"Durante o runtime o JIT do Java pode compilar 'hot spots' de um bytecode para código nativo aplicando otimizações, mas nesse ponto coisas como generics já terão sido resolvidas pelo pré-compilador."
não importa. fiz vc admitir que a compilação ocorre em tempo de execução. ;)
"até para usar chamadas reflexivas vc. precisa de permissão do SecurityManager"
é, nosso "SecurityManager" tmb não gosta muito de eval e nos limita tanto quanto o do Java. Estamos pensando em substituí-lo ou gerar um core dump... ;)
"Ao menos quando eu termino de ler um código Java, ainda que longo, eu o compreendi. Ao invés de ficar horas olhando..."
Algumas pessoas gostam de programar no nível de domínio atual e por isso criam sub linguagens específicas de domínio em cima da própria linguagem de programação e programam nessa abstração mais alta e mais próxima da realidade da aplicação, ao invés de ficar tentando agradar ao compilador com declarações redundantes ou mecanismos de controle arcaicos.
Ou talvez vc estivesse falando de script-kiddies?...
"eu não preciso gastar minha noite toda depurando meu código..."
Mas há aqueles "momentos" com ela em que vc preferiria ficar depurando COBOL às 4 da manhã! :)))
"os 'ditadores benevolentes' acabam tendo muito mais trabalho...Pois precisam validar *tudo*."
eles podem sempre delegar... ;)
"aviso que eu vou parar quando cada linha só couber duas palavras."
já posso adiantar minha 2 palavras finais: Java sucks!! :)))
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de anonymous
16/02/06 22:53
> "a vida não é filme e você não entendeu...": para finalizar este "debate" gostaria de pedir desculpas a sua pessoa e a todos da lista que naum te orbigacao de ficar lendo estas resgacao q nada tem a ver com o titulo inicial, qnt ao meu teclado vai bem obrigado ,a vontande de usa-lo q falta :)
Comentário de Copernico Vespucio
17/02/06 16:54 - usuário registrado #4868
nem tanto: E é por isso que não pode: uma closure por definição *é*...
Vc. só falou de closures. E eu só tenho falado até agora que vc. está enganado: Classes anônimas não têm nada a ver com closures. Se vc. não pode fazer comparação com todos os tipos de classes internas (pq são todos estruturalmente iguais), se vc. não pode comparar com qualquer uma delas, não pode comparar com nenhuma.
Presto, "herança"! Possível em qualquer linguagem, mas particularmente em linguagens dinamicamente tipadas, se precisar...
Não com a robustez que a tipagem estática oferece.
semelhante a void exec( void (*callback)( AbstractActionStruct *act ), AbstractActionStruct *act )?
Agora eu tenho *certeza* de que a minha versão é mais legível...
ah! parece que afinal C# e seu sistema de tipos unificado agitou as coisas no mundo Java...
Nope! :-) Autoboxing e Generics já eram requisições "antigas" no JCP. Autoboxing estava esperando por uma implementação eficiente e Generics estava esperando a votação sobre a sintaxe mais adequada e o melhor modelo a ser usado, dentre várias propostas. Type Safe Enum (não confundir com o enum do C++, que não tem segurança de tipo) é uma implementação de um pattern definido pelo autor do livro Effective Java, que é membro do JCP. Na verdade, bem poucas mudanças no J2SE5.0 tiveram alguma coisa a ver com o "ataque C#", em maioria as mais frívolas, como static import.
confesso que é uma boa. mais memória do que Java já usa...
Bem menos seria no Smalltalk (com uma API equivalente). E cada vez menos, é o nosso objetivo.
não importa. fiz vc admitir que a compilação ocorre em tempo de execução. ;)
Sua retórica não funciona comigo. Já fiz você entender a diferença entre compilação em tempo de projeto e JIT. Não trolle!
é, nosso "SecurityManager" tmb não gosta muito de eval e nos limita tanto quanto o do Java. Estamos pensando em substituí-lo ou gerar um core dump... ;)
Nosso? Não entendi...
Algumas pessoas gostam de programar no nível de domínio atual e por isso criam sub linguagens específicas de domínio em cima da própria linguagem de programação e programam nessa abstração mais alta e mais próxima da realidade da aplicação
Quer coisa mais redundante que isso?
Mas há aqueles "momentos" com ela em que vc preferiria ficar depurando COBOL às 4 da manhã! :)))
Sou um homem feliz ao afirmar que esses momentos não existem, já a dois anos... ;-) Deixe que o COBOL passe suas noites sozinho.
eles podem sempre delegar... ;)
Esse foi o meio mais original que eu já vi pra incluir um link.
Mas Deus sabe que encontrar pessoas competentes a quem se possa delegar está cada dia mais difícil...
já posso adiantar minha 2 palavras finais: Java sucks!! :)))
As minhas duas últimas palavras na resposta vão ser:
Ciao, Troll! ;-P
P.S: Vc. sabia que "m * a * d * r * u * g * a * d * a * s" é uma "m e d i c i n e l i k e s p a m w o r d" por aqui?
Vc. só falou de closures. E eu só tenho falado até agora que vc. está enganado: Classes anônimas não têm nada a ver com closures. Se vc. não pode fazer comparação com todos os tipos de classes internas (pq são todos estruturalmente iguais), se vc. não pode comparar com qualquer uma delas, não pode comparar com nenhuma.
Presto, "herança"! Possível em qualquer linguagem, mas particularmente em linguagens dinamicamente tipadas, se precisar...
Não com a robustez que a tipagem estática oferece.
semelhante a void exec( void (*callback)( AbstractActionStruct *act ), AbstractActionStruct *act )?
Agora eu tenho *certeza* de que a minha versão é mais legível...
ah! parece que afinal C# e seu sistema de tipos unificado agitou as coisas no mundo Java...
Nope! :-) Autoboxing e Generics já eram requisições "antigas" no JCP. Autoboxing estava esperando por uma implementação eficiente e Generics estava esperando a votação sobre a sintaxe mais adequada e o melhor modelo a ser usado, dentre várias propostas. Type Safe Enum (não confundir com o enum do C++, que não tem segurança de tipo) é uma implementação de um pattern definido pelo autor do livro Effective Java, que é membro do JCP. Na verdade, bem poucas mudanças no J2SE5.0 tiveram alguma coisa a ver com o "ataque C#", em maioria as mais frívolas, como static import.
confesso que é uma boa. mais memória do que Java já usa...
Bem menos seria no Smalltalk (com uma API equivalente). E cada vez menos, é o nosso objetivo.
não importa. fiz vc admitir que a compilação ocorre em tempo de execução. ;)
Sua retórica não funciona comigo. Já fiz você entender a diferença entre compilação em tempo de projeto e JIT. Não trolle!
é, nosso "SecurityManager" tmb não gosta muito de eval e nos limita tanto quanto o do Java. Estamos pensando em substituí-lo ou gerar um core dump... ;)
Nosso? Não entendi...
Algumas pessoas gostam de programar no nível de domínio atual e por isso criam sub linguagens específicas de domínio em cima da própria linguagem de programação e programam nessa abstração mais alta e mais próxima da realidade da aplicação
Quer coisa mais redundante que isso?
Mas há aqueles "momentos" com ela em que vc preferiria ficar depurando COBOL às 4 da manhã! :)))
Sou um homem feliz ao afirmar que esses momentos não existem, já a dois anos... ;-) Deixe que o COBOL passe suas noites sozinho.
eles podem sempre delegar... ;)
Esse foi o meio mais original que eu já vi pra incluir um link.
Mas Deus sabe que encontrar pessoas competentes a quem se possa delegar está cada dia mais difícil...
já posso adiantar minha 2 palavras finais: Java sucks!! :)))
As minhas duas últimas palavras na resposta vão ser:
Ciao, Troll! ;-P
P.S: Vc. sabia que "m * a * d * r * u * g * a * d * a * s" é uma "m e d i c i n e l i k e s p a m w o r d" por aqui?
Comentário de nemesis
17/02/06 22:20 - usuário registrado #1514
tchau!: "Classes anônimas não têm nada a ver com closures."
Vou te dar uma dica: uma classe pode ser implementada como uma função que retorna uma closure capaz de aceitar "mensagens" e disparar funções de escopo mais interno de acordo. Ou seja, uma função que cria instâncias. Isso em linguagens como Scheme. Uma classe anônima em Java é bastante semelhante a uma closure.
"Agora eu tenho *certeza* de que a minha versão é mais legível..."
talvez se eu fizesse
typedef void (*AbstractActionCallback)( AbstractActionStruct *act );
exec( AbstractActionCallback *aac, AbstractActionStruct *act );
ficasse melhor? nada como uma linguagem te deixar definir aliases, hein? ;)
"coisa a ver com o 'ataque C#', em maioria as mais frívolas, como static import."
eu gostaria que Java tivesse imports com aliases, como em Python ou C#... nada de pôr o kilométrico path do módulo para desambiguar possíveis colisões de nomes...
"Já fiz você entender a diferença entre compilação em tempo de projeto e JIT."
não, não fez não: JIT ocorre em tempo de execução, aqui e ali gerando código nativo. Lembre-se do nome completo JIT: Just-in-time compilation...
"Nosso? Não entendi..."
nosso gerente de projetos velho cobolista de guerra... ;)
"Quer coisa mais redundante que isso?"
claro, claro! Muito menos redundante do que programar no nível de negócios do usuário é programar em uma linguagem que reclama se vc esqueceu de algum ponto-e-vírgula e outras irrelevâncias de baixo nível para agradar ao compilador...
"Sou um homem feliz ao afirmar que esses momentos não existem"
eu espero qualquer coisa de um programador Java... ;)
"Ciao, Troll!"
tchau, javaboy!
"P.S: Vc. sabia que 'm * a * d * r * u * g * a * d * a * s' é uma 'm e d i c i n e l i k e s p a m w o r d' por aqui?"
descobri depois de umas 2 horas tentando postar a resposta, até que substituí por "manhã"... :P
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Vou te dar uma dica: uma classe pode ser implementada como uma função que retorna uma closure capaz de aceitar "mensagens" e disparar funções de escopo mais interno de acordo. Ou seja, uma função que cria instâncias. Isso em linguagens como Scheme. Uma classe anônima em Java é bastante semelhante a uma closure.
"Agora eu tenho *certeza* de que a minha versão é mais legível..."
talvez se eu fizesse
typedef void (*AbstractActionCallback)( AbstractActionStruct *act );
exec( AbstractActionCallback *aac, AbstractActionStruct *act );
ficasse melhor? nada como uma linguagem te deixar definir aliases, hein? ;)
"coisa a ver com o 'ataque C#', em maioria as mais frívolas, como static import."
eu gostaria que Java tivesse imports com aliases, como em Python ou C#... nada de pôr o kilométrico path do módulo para desambiguar possíveis colisões de nomes...
"Já fiz você entender a diferença entre compilação em tempo de projeto e JIT."
não, não fez não: JIT ocorre em tempo de execução, aqui e ali gerando código nativo. Lembre-se do nome completo JIT: Just-in-time compilation...
"Nosso? Não entendi..."
nosso gerente de projetos velho cobolista de guerra... ;)
"Quer coisa mais redundante que isso?"
claro, claro! Muito menos redundante do que programar no nível de negócios do usuário é programar em uma linguagem que reclama se vc esqueceu de algum ponto-e-vírgula e outras irrelevâncias de baixo nível para agradar ao compilador...
"Sou um homem feliz ao afirmar que esses momentos não existem"
eu espero qualquer coisa de um programador Java... ;)
"Ciao, Troll!"
tchau, javaboy!
"P.S: Vc. sabia que 'm * a * d * r * u * g * a * d * a * s' é uma 'm e d i c i n e l i k e s p a m w o r d' por aqui?"
descobri depois de umas 2 horas tentando postar a resposta, até que substituí por "manhã"... :P
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")
Comentário de Copernico Vespucio
20/02/06 12:47 - usuário registrado #4868
Então adiós.: Uma classe anônima em Java é bastante semelhante a uma closure
Onde vc. fala de "filosofia" e aplicabilidade, eu falor de *estrutura* da coisa. Para mim, embora possam servir ao mesmo escopo aparente, as duas coisas não têm nenhuma estrutura em comum. Vc. está falando de uma coisa, eu de outra, jamais chegaremos a lugar nenhum por aqui.
talvez se eu fizesse
typedef void (*AbstractActionCallback)( AbstractActionStruct *act );
exec( AbstractActionCallback *aac, AbstractActionStruct *act );
A mesma ilegibilidade em menos linhas... :-P
JIT ocorre em tempo de execução, aqui e ali gerando código nativo. Lembre-se do nome completo JIT: Just-in-time compilation...
Foi o que eu disse ué... Vc. entendeu direitinho a diferença entre compilação em tempo de projeto e compilação em runtime...
nosso gerente de projetos velho cobolista de guerra
Nosso = de vocês, certo? Mas já trabalhei com coboleiros, gente boa, em sua maioria (linguagem simples, poucas instruções, mas um pesadelo para dar manutenção).
programar em uma linguagem que reclama se vc esqueceu de algum ponto-e-vírgula e outras irrelevâncias de baixo nível para agradar ao compilador
Groovy usa ponto-e-virgula de forma facultativa. Eu não gosto de algo que pode ser usado de vez em quando assim, de vez em quando assado. E ao abolir o ponto-e-virgula, seu compilador vai precisar de outro separador de instrução e na minha opinião o CRLF é péssimo pra isso.
eu espero qualquer coisa de um programador Java... ;)
É bom saber que fazemos milagres! :-D
eu gostaria que Java tivesse imports com aliases, como em Python ou C#... nada de pôr o kilométrico path do módulo para desambiguar possíveis colisões de nomes...
Tá aí! *Isso* é realmente interessante, à primeira vista. Boa sugestão. Eu vou verificar se esse requerimento já não existe, avaliar as consequências e, se não existir, eu mesmo dou um jeito de pedir no fórum do Dolphin, ok?
descobri depois de umas 2 horas tentando postar a resposta, até que substituí por "manhã"... :P
Pô Brain... Tá lendo isso? Dá um jeito nessa lista de palavras (ou nesse mecanismo que diz que tá errado, mas não diz o quê) que a coisa tá triste!
Onde vc. fala de "filosofia" e aplicabilidade, eu falor de *estrutura* da coisa. Para mim, embora possam servir ao mesmo escopo aparente, as duas coisas não têm nenhuma estrutura em comum. Vc. está falando de uma coisa, eu de outra, jamais chegaremos a lugar nenhum por aqui.
talvez se eu fizesse
typedef void (*AbstractActionCallback)( AbstractActionStruct *act );
exec( AbstractActionCallback *aac, AbstractActionStruct *act );
A mesma ilegibilidade em menos linhas... :-P
JIT ocorre em tempo de execução, aqui e ali gerando código nativo. Lembre-se do nome completo JIT: Just-in-time compilation...
Foi o que eu disse ué... Vc. entendeu direitinho a diferença entre compilação em tempo de projeto e compilação em runtime...
nosso gerente de projetos velho cobolista de guerra
Nosso = de vocês, certo? Mas já trabalhei com coboleiros, gente boa, em sua maioria (linguagem simples, poucas instruções, mas um pesadelo para dar manutenção).
programar em uma linguagem que reclama se vc esqueceu de algum ponto-e-vírgula e outras irrelevâncias de baixo nível para agradar ao compilador
Groovy usa ponto-e-virgula de forma facultativa. Eu não gosto de algo que pode ser usado de vez em quando assim, de vez em quando assado. E ao abolir o ponto-e-virgula, seu compilador vai precisar de outro separador de instrução e na minha opinião o CRLF é péssimo pra isso.
eu espero qualquer coisa de um programador Java... ;)
É bom saber que fazemos milagres! :-D
eu gostaria que Java tivesse imports com aliases, como em Python ou C#... nada de pôr o kilométrico path do módulo para desambiguar possíveis colisões de nomes...
Tá aí! *Isso* é realmente interessante, à primeira vista. Boa sugestão. Eu vou verificar se esse requerimento já não existe, avaliar as consequências e, se não existir, eu mesmo dou um jeito de pedir no fórum do Dolphin, ok?
descobri depois de umas 2 horas tentando postar a resposta, até que substituí por "manhã"... :P
Pô Brain... Tá lendo isso? Dá um jeito nessa lista de palavras (ou nesse mecanismo que diz que tá errado, mas não diz o quê) que a coisa tá triste!
Sleepycat Software é responsável pela tradicional implementação *nix para databases embutidos e de alta-performance, na forma do Berkeley DB. Talvez finalmente a Oracle tenha se dado conta que nem todos precisam de um servidor rodando em clusters?
E JBoss recentemente começou a sentir a competição provida pelo Apache Geronimo. A Oracle usa infraestrutura java e seria conveniente ter uma implementação dessas sob suas rédeas...
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")