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

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

Bruno Laturner wrote: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

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.

This message was edited 1 time. Last update was at 13/08/2008 13:41:14

thingol wrote:Mas realmente é uma gambiarra que existe porque a alternativa mais intuitiva (usar "soma (2, 3)"), segundo o sr. Neal Gafter, tem alguns problemas de ambigüidade sintática que são difíceis de resolver.

sergiotaborda wrote: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.

Respondendo ambos ao mesmo tempo:

Resolvemos da mesma forma que fazemos com atributos do objeto e variáveis locais, ambos com o mesmo identificador, usando escopo.

Edit: A questão não é "não ter invoke", é ele não ser a única opção.

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

Bruno Laturner wrote:
Respondendo ambos ao mesmo tempo:

Resolvemos da mesma forma que fazemos com atributos do objeto e variáveis locais, ambos com o mesmo identificador, usando escopo.

Edit: A questão não é "não ter invoke", é ele não ser a única opção.

Tudo bem que não seja a única opção. Mas existem opções melhores que outras....
Não entendi como o escopo poderia ajudar no exemplo que dei. Explique melhor essa ideia.

This message was edited 1 time. Last update was at 13/08/2008 13:55:35

peczenyj wrote:public class X { public X doSomething() { /* statement */ return this; } }

Como posso criar uma closure que retorne ela mesma? Faz sentido?

Usa o Y Combinator.

This message was edited 1 time. Last update was at 13/08/2008 14:09:50

sergiotaborda wrote:Não entendi como o escopo poderia ajudar no exemplo que dei. Explique melhor essa ideia.

function() não seria o método da classe, seria a função mais próxima definida no escopo.

É um problema para visualizar isso na hora da manutenção? Bem, sim.

This message was edited 1 time. Last update was at 14/08/2008 00:21:56

Leonardo3001 wrote:
Em Python, não sei. Mas em Ruby, fica assim:

lista = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] puts lista.select {|a| a % 2 == 0}

Apesar que eu acho que você foi injusto com Java, pois boa parte do seu código é para adicionar um método em ArrayList<E>. Na prática, quando Closure for real, novos métodos serão (ou deveriam ser) adicionados nas coleções, e ninguém fará isso à mão.

Portanto, para comparação, vou considerar no código Java apenas a classe com método estático main.
Fica assim:

Java (com closure) -> 9 linhas
Scheme -> 3 linhas
Ruby -> 2 linhas

Na maioria das linguagens com caracteristicas funcionais esse exemplo do filtro e possivel em 1 linha de codigo. Passa ser mais importante entao a sintaxe da linguagem. Neste aspecto Ruby nao e das piores mas acho que poderia ser melhor.

editado: onde escrevi sintaxe queria dizer na verdade 'expressividade'.

This message was edited 1 time. Last update was at 13/08/2008 16:10:41

louds wrote:

peczenyj wrote:public class X { public X doSomething() { /* statement */ return this; } }

Como posso criar uma closure que retorne ela mesma? Faz sentido?

Usa o Y Combinator.

Agora boiei tb.

Primeiro nao entendi porque uma funcao se daria ao trabalho de retornar ela mesma. Eu fico imaginando passar ou receber essa funcao e alguem precisar executa-la para que retorne a propria (digo ja enclosured).

Y Combinator eu sei apenas que e pra criar funcoes recursivas... mas como nao consegui entender o problema muito menos consegui ligar com a solucao.

Talvez fizesse mais sentido uma funcao (e nao uma closure) que retornasse ela mesma.........

JavaBaby Membro desde: 22/08/2005 16:38:08 Mensagens: 79 Offline

Alguém pode me dar um exemplo prático de, como closures poderia resolver um problema, o qual não o consegueriamos sem ele?
Só para eu entender onde realmente eu poderia empregá-lo...

Alguém pode me dar um exemplo prático de, como closures poderia resolver um problema, o qual não o consegueriamos sem ele?

Muita gente passa a vida inteira sem sentir a menor falta delas. Closures, da maneira que estamos nos referindo aqui é uma maneira de usar higher order procedures, que nos permitem 'aumentar' nosso poder de abstração e a expressividade dos nossos programas. Aqui tem um ótimo exemplo de como expressar derivadas usando high order procedures, é menos complicado do que parece.

cmoscoso wrote:
Agora boiei tb.

Primeiro nao entendi porque uma funcao se daria ao trabalho de retornar ela mesma. Eu fico imaginando passar ou receber essa funcao e alguem precisar executa-la para que retorne a propria (digo ja enclosured).

Y Combinator eu sei apenas que e pra criar funcoes recursivas... mas como nao consegui entender o problema muito menos consegui ligar com a solucao.

Talvez fizesse mais sentido uma funcao (e nao uma closure) que retornasse ela mesma.........

O YC permite a função ter uma referencia a si própria, agora se ela vai se chamar recursivamente ou simplesmente retornar o valor é indiferente.

JavaEvangelist Membro desde: 23/10/2007 10:08:29 Mensagens: 470 Offline

louds wrote:
O YC permite a função ter uma referencia a si própria, agora se ela vai se chamar recursivamente ou simplesmente retornar o valor é indiferente.

Louds, vc tem razao,

E pq ando lendo sobre cultura lisp onde closures sao implementadas na linguagem desde sempre pra trabalhar com funcoes anonimas.

Mas pensando melhor sobre nomenclatura em outras linguagens onde closures sao implementadas posteriormente, talvez seja melhor mesmo falar "retornar uma closure", pra diferenciar de outro mecanismo utilizado ate entao pela linguagem para passar/retornar blocos de codigo (classes internas anonimas em Java). Parece que em lisp essa diferenciacao nao é importante do ponto de vista pro programador.

O que vc acha?

facholi wrote:Alguém pode me dar um exemplo prático de, como closures poderia resolver um problema, o qual não o consegueriamos sem ele?
Só para eu entender onde realmente eu poderia empregá-lo...

Da mesma forma que não existe problema que OO resola que não seja resolvido antes você não vai encontrar um exemplo destes. A questão é apenas a maneira como resolvemos.

cmoscoso wrote:

louds wrote:
O YC permite a função ter uma referencia a si própria, agora se ela vai se chamar recursivamente ou simplesmente retornar o valor é indiferente.

Louds, vc tem razao,

E pq ando lendo sobre cultura lisp onde closures sao implementadas na linguagem desde sempre pra trabalhar com funcoes anonimas.

Mas pensando melhor sobre nomenclatura em outras linguagens onde closures sao implementadas posteriormente, talvez seja melhor mesmo falar "retornar uma closure", pra diferenciar de outro mecanismo utilizado ate entao pela linguagem para passar/retornar blocos de codigo (classes internas anonimas em Java). Parece que em lisp essa diferenciacao nao é importante do ponto de vista pro programador.

O que vc acha?

Acho que levará bastante tempo até a comunidade realizar o poder do que é possível com closures.

Vejo isso pelo .NET. As pessoas ainda estão explorando muito o C# 3.0.

O problema do Java é que ele ficou "institucionalizado" - é uma linguagem didática e comercial, como se fosse um Cobol moderno (sempre que quero chocar um Java-maníaco, digo para ele que "Java == COBOL").
E é por isso que acabam se opondo às mudanças; como se sabe, é mais difícil fazer uma mudança que não destrua tudo que já foi feito - como foi o caso do "generics", que tentou ser retrocompatível com os programas antigos e ficou extremamente difícil de entender - que uma mudança que destrua tudo (como é o caso de cada versão do C# que aparece).
A nova mudança (closures), que tem de ser retrocompatível com os programas antigos, também é difícil de entender, e fica um pouco abaixo das expectativas - se a Sun simplesmente fosse a única dona do Java, e ela se notabilizasse por destruir tudo que foi feito antes - o que não é bem o que a Sun faz; programas antigos em C que rodam em antigas máquinas Sparc continuam rodando nas novas de hoje em dia sem problemas - então ela poderia fazer algo mais simples, como o que apareceu no C# 3.0.
O Neal Gafter, embora não trabalhe mais para a Sun, compreende o que deve ser feito para não afetar os programas antigos, e é por isso que a parte de Closures é menos ambiciosa e mais complicada do que ela poderia ser.

JavaEvangelist Membro desde: 23/10/2007 10:08:29 Mensagens: 470 Offline

Pro Louds:
Sera que os programadores nao explorarao o poder de closures em Java por falta de ambicao na implementacao (o thingol colocou como 'a coisa certa', ignorar compatibilidade retroativa) ou por que os proprios programadores nao conhecem tecnicas de programacao funcional?

Pro Thingol:
Deve ter sido mesmo um trabalho do cao pra implementar closures em Java mas vc acha mesmo que a interface ficou tao ruim ao ponto de ser pior pra entender do que todas aquelas regrinhas especificas do uso de classes internas, sintaxe fora do convencional para classes anonimas, ter que declarar variaveis final?

A minha opiniao é que sim, simplicidade na implementacao importa mas compatibilidade tb é importante ate certo ponto.

"Java == COBOL Moderno", vc disse tudo aqui, eu tenho a mesma impressao mas.. isso é necessariamente algo ruim?

Apenas se Java for sua unica opcao para tudo.