Protótipo de Closures em Java está "feature-complete"

Forum Spammer Membro desde: 23/01/2008 11:14:35 Mensagens: 1079 Offline

sergiotaborda wrote:[Bruno Laturner]invoke em que ser chamado explicitamente?

Acho sacanagem ter que fazer soma.invoke(2,3) em vez de soma(2,3). Se closures são funções, ajam como tal.

A meu ver ai é que tá a sacada... closures são objetos. "funções puras" continuam não existindo.

Imagine que vc passa uma função com parametro de um método tipo assim

<T> void doSomething(List<T> list, { T=> void} function ) { for (T t : list){ function.invoke(t); } }
Se vc não tiver o invoke, como executaria a função em cima de cada t ?
Algo como function(t) implicaria que function é um método da classe, o que não é verdade.

Segundo autor da fonte confiável, "Anonima" vou colocar aqui a resposta que achei plausível.

"Closure não será incorporado pela linguagem (pelo menos em Java 7) segundo palavras do próprio Mister M (Michael Nascimento) e mesmo na comunidade internacional, houve uma arrefecida desse tópico."

Agora segundo, anonimo, ai vem a resposta !!!

A sua afirmação sobre uma forma de se declarar uma classe simplificada que possuirá apenas uma função não deixa de ser verdade no contexto de Java.A primeira utilização seria para contemplar um problema que a comunidade java reclama, a verborragia da linguagem.

Seria melhor fazer isso:

ou isso (usando a notação proposta pelo Neal Gafter)?

--Classe Endereco usada acima --

----
PS: haveria uma nova sobrecarga no Collections.sort, para aceitar uma "função"

Essa seria então a idéia inicial: Criar um açúcar sintático eliminando a regra de que tudo tem de ser uma classe em java(nesse contexto, "explodimos" uma das regras de Ouro em Java).

Isso é bom, por limpar a quantidade código digitada pelo desenvolvedor, mas essa seria a resposta mais simplória.

O uso de closures não é apenas isso. Ele é muito mais do que isso!

Se Java aceitar tal facilidade do jeito que foi concebida, e suportar o método invoke que utilizou no código abaixo nós teremos uma das qualidades mais interessantes que uma linguagem ofereceria: a injeção de código em lacunas a serem preenchidas pelos desenvolvedores.

Design patterns como o Template, não precisariam ser implementados da maneira que existe em muitos frameworks em Java (exemplo classico é o que Struts faz).

.NET caminhou para esse lado, ao suportar os métodos anônimos (anonymous methods) e que oferece atualmente o LinQ, que é uma maneira de acessa a camada de dados de maneira transparente.

Outro ponto, bem citado pelo Joel Spolsky e é bem verdade, está no seguinte link:

http://www.joelonsoftware.com/items/2006/08/01.html

Marcio Duran wrote:Essa seria então a idéia inicial: Criar um açúcar sintático eliminando a regra de que tudo tem de ser uma classe em java(nesse contexto, "explodimos" uma das regras de Ouro em Java).

O que acontece é que as classes eliminadas neste caso são boilerplates em forma de classes (frequentemente anônimas) que não representam nenhuma entidade real do sistema e estão lá apenas por conta de limitações da linguagem. Ou seja, não ocorre nenhuma explosão da OO, e sim flexibilização da linguagem que acaba por abstrair a necessidade de criar-se uma classe específica para um trabalho.

Marcio Duran wrote:

Essa seria então a idéia inicial: Criar um açúcar sintático eliminando a regra de que tudo tem de ser uma classe em java(nesse contexto, "explodimos" uma das regras de Ouro em Java).

Essa regra de ouro eu não conheço. Nem tudo é objeto em java. int, long .etc não são objetos.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1977 Offline

Ssalgado wrote:

Marcio Duran wrote:

Essa seria então a idéia inicial: Criar um açúcar sintático eliminando a regra de que tudo tem de ser uma classe em java(nesse contexto, "explodimos" uma das regras de Ouro em Java).

Essa regra de ouro eu não conheço. Nem tudo é objeto em java. int, long .etc não são objetos.

Java é uma linguagem fortemente orientada a objetos e tipos. Todas as estruturas são objetos.
int,long etc.. não são estruturas. Mas os primitivos são exceções ha regra introduzidos apenas por questões de performance e limitação (lembre-se que Java foi criado originalmente para setop boxes com ambientes limitados. isso fico enrraizado na linguagem e o objetvo continua válido ainda hoje. )
Por isso em java temos tipos primitivos e objetos. Objetos por principio e primitivos por questões tecnicas de performance , etc..

Agora, introduzindo um novo tipo chamado "função" ele seria primitivo ou objeto ?

O ponto é que Java tem as suas estruturas amarradas como objetos. Então ,sendo uma função uma estrutura ela deveria ser um objeto. Se ela não for ela será um primitivo. Mas ser um primitivo viola a regra de que apenas os primitivos são primitivos e o resto são objetos. Por outro lado estariamos confiando que uma função é um tipo especial de primitivo já que não ha promoção entre int e function, mas ha entre int e double, por exemplo. Então a escolha recai logicamente em que função tem que ser um objeto.
E é isso que os Function Types são. Objetos que implementam interfaces especiais. Primitivos continuam sendo primitivos e o resto são objetos.

Porderiamos abrir um terceiro tipo e java passaria a ter primitivos, objetos e funções.
Sendo que primitivo é uma exceção a objeto , função seria uma exceção a ambos. Isso trás vários problemas tecnicos e até fiolosoficos. A escolha de tornar função objetos é simples, clara e de acordo com a politica usada até agora. Até anotations são objetos. E repare que eles são completamente intropectivos ( não pdoe dar um new em annotation). function type segue o mesmo caminho.

sergiotaborda wrote:
Java é uma linguagem fortemente orientada a objetos e tipos. Todas as estruturas são objetos.
int,long etc.. não são estruturas. Mas os primitivos são exceções ha regra introduzidos apenas por questões de performance e limitação (lembre-se que Java foi criado originalmente para setop boxes com ambientes limitados. isso fico enrraizado na linguagem e o objetvo continua válido ainda hoje. )
Por isso em java temos tipos primitivos e objetos. Objetos por principio e primitivos por questões tecnicas de performance , etc..

Isso não é verdade. A distinção existe por pura incompetência dos designers da linguagem e máquina virtual. A CLR não possui qualquer forma de tipo primitivo
e tem performance na mesma categoria do Java. Alimentar um mito envolva desses erros é um enorme desserviço a todos aqui no GUJ.

sergiotaborda wrote:
Agora, introduzindo um novo tipo chamado "função" ele seria primitivo ou objeto ?

Essa discussão de primitivo ou objeto é enraizada na ignorância da distinção entre ambos.
Não faz sentido argumentar em cima disso quando, fundamentalmente, deveriam questionar sobre
quais carregam semântica de value type/scalar ou reference type.
Pois está a distinção dos tipos em Java rotulados de primitivos por falha dos designers da linguagem.

Curiosamente, esta é uma exigência feita a mais de uma década para a Sun, suportar tipos escalares
arbitrários.

sergiotaborda wrote:
O ponto é que Java tem as suas estruturas amarradas como objetos. Então ,sendo uma função uma estrutura ela deveria ser um objeto. Se ela não for ela será um primitivo. Mas ser um primitivo viola a regra de que apenas os primitivos são primitivos e o resto são objetos. Por outro lado estariamos confiando que uma função é um tipo especial de primitivo já que não ha promoção entre int e function, mas ha entre int e double, por exemplo. Então a escolha recai logicamente em que função tem que ser um objeto.
E é isso que os Function Types são. Objetos que implementam interfaces especiais. Primitivos continuam sendo primitivos e o resto são objetos.

Porderiamos abrir um terceiro tipo e java passaria a ter primitivos, objetos e funções.
Sendo que primitivo é uma exceção a objeto , função seria uma exceção a ambos. Isso trás vários problemas tecnicos e até fiolosoficos. A escolha de tornar função objetos é simples, clara e de acordo com a politica usada até agora. Até anotations são objetos. E repare que eles são completamente intropectivos ( não pdoe dar um new em annotation). function type segue o mesmo caminho.

Seu questionamento é completamente descabido. Pois uma closure é isomorfa a um tipo por referência, a um objeto. Anotações são tipos comuns a linguagem e a questão
de poderem ser usadas para anotar membros é ortogonal, elas são apenas uma categoria particular de interfaces.

Sérgio, por favor, faça sua lição de casa antes de sair disseminando desinformação.

This message was edited 1 time. Last update was at 24/08/2008 19:18:08

louds wrote:

sergiotaborda wrote:
Java é uma linguagem fortemente orientada a objetos e tipos. Todas as estruturas são objetos.
int,long etc.. não são estruturas. Mas os primitivos são exceções ha regra introduzidos apenas por questões de performance e limitação (lembre-se que Java foi criado originalmente para setop boxes com ambientes limitados. isso fico enrraizado na linguagem e o objetvo continua válido ainda hoje. )
Por isso em java temos tipos primitivos e objetos. Objetos por principio e primitivos por questões tecnicas de performance , etc..

Isso não é verdade. A distinção existe por pura incompetência dos designers da linguagem e máquina virtual. A CLR não possui qualquer forma de tipo primitivo

Devo compreender das suas palavras que vc só usa Long, Integer, Boolean, Double , etc.. nos seus programas ? e nunca long, int , boolean , double ?
Devo compreender das suas palavras que escreve ifs assim :

louds wrote:

sergiotaborda wrote:
Agora, introduzindo um novo tipo chamado "função" ele seria primitivo ou objeto ?

Essa discussão de primitivo ou objeto é enraizada na ignorância da distinção entre ambos.
Não faz sentido argumentar em cima disso quando, fundamentalmente, deveriam questionar sobre
quais carregam semântica de value type/scalar ou reference type.
Pois está a distinção dos tipos em Java rotulados de primitivos por falha dos designers da linguagem.

Vc quer descer em um nivel que não estava na mensagem que respondi.

louds wrote:

sergiotaborda wrote:
O ponto é que Java tem as suas estruturas amarradas como objetos. Então ,sendo uma função uma estrutura ela deveria ser um objeto. Se ela não for ela será um primitivo. Mas ser um primitivo viola a regra de que apenas os primitivos são primitivos e o resto são objetos. Por outro lado estariamos confiando que uma função é um tipo especial de primitivo já que não ha promoção entre int e function, mas ha entre int e double, por exemplo. Então a escolha recai logicamente em que função tem que ser um objeto.
E é isso que os Function Types são. Objetos que implementam interfaces especiais. Primitivos continuam sendo primitivos e o resto são objetos.

Porderiamos abrir um terceiro tipo e java passaria a ter primitivos, objetos e funções.
Sendo que primitivo é uma exceção a objeto , função seria uma exceção a ambos. Isso trás vários problemas tecnicos e até fiolosoficos. A escolha de tornar função objetos é simples, clara e de acordo com a politica usada até agora. Até anotations são objetos. E repare que eles são completamente intropectivos ( não pdoe dar um new em annotation). function type segue o mesmo caminho.

Seu questionamento é completamente descabido. Pois uma closure é isomorfa a um tipo por referência, a um objeto. Anotações são tipos comuns a linguagem e a questão
de poderem ser usadas para anotar membros é ortogonal, elas são apenas uma categoria particular de interfaces.

Chame o que quiser. Mas quando vc faz :

e usa reflection para obter x , x não é um tipo primitivo. Da mesma forma que function type também não é tipo primitivo. Esse era o ponto. A regra de ouro citada é exatamente essa "apenas os primitivos são primitivos".
Que o mesmo que dizer que "em java tudo são objetos". A exceção - sendo um erro ou não - é uma exceção à regra.