Disponível primeiro protótipo de Closures  XML
Índice dos Fóruns » Assuntos gerais (Off-topic)
Autor Mensagem
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

O primeiro protótipo de Closures (recurso da linguagem que talvez seja incluído no Java 6 ou 7) está disponível.

Veja o post do sr. Neal Gafter em: http://gafter.blogspot.com/2007/10/java-closures-first-prototype.html
Um exemplo de programa com Closures:


[WWW]
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

Outro exemplo (em que criamos um Comparator que aceita qualquer Closure):
[WWW]
Tecnoage
GUJ Master

Membro desde: 13/03/2005 23:18:07
Mensagens: 1723
Localização: SP
Offline

Muito bom!!! Gostei!!! Sómente não gosto muito do incremento de sintaxe...

Arquiteto de Software
Sysped Solutions
R3 SAP CAT-83, NF-e, ECD, EFD, CT-e, MANAD, IN86
www.sysped.com.br
[Email] [WWW] [MSN]
ddduran
Virtual Machine Man
[Avatar]

Membro desde: 13/11/2006 16:44:54
Mensagens: 523
Offline

Na boa, desculpe a ignorancia, mas que beneficios isso vai trazer?
que outra linguagem tem esse recurso?

não vi nada ai que não podesse fazer de maneira bem mais legivel


no java 6 provavelmente não será mais incluido

Tecnoage
GUJ Master

Membro desde: 13/03/2005 23:18:07
Mensagens: 1723
Localização: SP
Offline

no java 7, no 6 não

Arquiteto de Software
Sysped Solutions
R3 SAP CAT-83, NF-e, ECD, EFD, CT-e, MANAD, IN86
www.sysped.com.br
[Email] [WWW] [MSN]
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

Escrevi Java 6 ou 7, mas na verdade seria 7 (Dolphin) ou 8 (não sei o nome código).

De qualquer maneira, os benefícios de closures são um pouco sutis, tanto é que muita gente está contra sua introdução na linguagem.

Quem nunca programou em outras linguagens com closures tem uma das seguintes opiniões:
- Não entendi e não gostei
- Até entendi, mas nada que uma anonymous class não resolva

Quem já programou com linguagens com closures tem uma das seguintes opiniões:
- Em Java ficou complicado demais
- Parece uma cópia mal-ajambrada do mesmo recurso que existe no Groovy

Linguagens com closures: Smalltalk, Groovy, Ruby, Python, Scala, C# (Visual Studio 2008), etc.

This message was edited 1 time. Last update was at 29/10/2007 14:49:44

[WWW]
peczenyj
Moderador
[Avatar]

Membro desde: 26/03/2006 23:25:37
Mensagens: 3191
Localização: Rio de Janeiro
Offline

O que eu acho estranho é esta sintaxe:

{int, int => int} closure;

Ok, não tem outra forma de fazer em Java que não seja esta mas em que ponto este recurso é diferente de uma classe interna anônima?

Parece um syntax sugar.

http://pacman.blog.br

'Não importa quanto alguém se dedique à tarefa. Ninguém consegue fazer a água da cascata cair para cima.'
[WWW]
ddduran
Virtual Machine Man
[Avatar]

Membro desde: 13/11/2006 16:44:54
Mensagens: 523
Offline

thingol wrote:
Quem nunca programou em outras linguagens com closures tem uma das seguintes opiniões:
- Não entendi e não gostei




eu estou nesse grupo ai :P hehehe

mas eu até entendi o codigo (com base nos prints), só não consegui ter a visão no que isso vai agregar.

This message was edited 1 time. Last update was at 29/10/2007 15:27:49

thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

Bom, não mostrei ainda os outros recursos de closures porque o protótipo ainda não os suporta.
Uma coisa que é muito legal é a implementação do comando "using" do C#, mas sem precisar de chumbar isso na linguagem.
Para quem não sabe o que é isso, o "using" serve para fechar (no C#), na marra, qualquer coisa que você definir como "fechável" - um Connection, um InputStream etc, sem que você precise usar um monte de "try/catch/finally". Exemplo:


seria o equivalente a:


o que é uma maravilha para esse tipo de código chato e sujeito a erros.
[WWW]
Filipe Sabella
GUJ Expert

Membro desde: 12/03/2003 11:25:57
Mensagens: 4680
Offline

Ótimo ;D

Apesar de não ter pensado nas implicações disso, eu realmente preferi a sugestão do eirikma nos comentários.
Ao invés disso,

isso:

This message was edited 1 time. Last update was at 29/10/2007 15:41:16


Former LIPE.
[ICQ]
rodrigoallemand
GUJ Ranger
[Avatar]

Membro desde: 21/02/2005 20:19:47
Mensagens: 972
Localização: Rio de Janeiro, Recreio!!!
Offline

Acho que pro pessoal do Groovy, do RoR entre outras isso fica mais fácil de entender... mas pro pessoal que não viu, seja por qualquer motivo, fica mais dificil... Eu, por exemplo, nunca vi Groovy ou RoR por falta de tempo e de interesse... Java tá me deixando bastante ocupado ainda!!! hehehehe

Rodrigo Allemand

A culpa é minha e eu a coloco em quem eu quizer!. (Homer Simpson)
http://blog.rodrigoallemand.com.br
[WWW] [MSN]
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

O eirikma está vendo que nesse caso em particular, um closure é algo parecido com um ponteiro de função, e ele está propondo uma sintaxe semelhante a ponteiros de função que é similar à maior parte das linguagens orientadas a objetos (C++, Object Pascal etc.).

[WWW]
Rodrigo Carvalho Auler
Virtual Machine Man

Membro desde: 14/02/2003 15:59:17
Mensagens: 576
Localização: Rio de Janeiro
Offline

LIPE wrote:
isso:

Os dois me parecem confusos. Poderia ter a possibilidade fazer como os delegates do C#.


E pra que invoke?

Pq não simplesmente:



[]'s

Rodrigo Auler
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17543
Offline

Por isso é que é um protótipo.
Provavelmente esse "invoke" vai acabar caindo fora, já que não é ortogonal (comparando com a sintaxe clássica de chamada de funções através de ponteiros, como é o caso do C++ ou do Object Pascal.). É isto que você estava mencionando?

[WWW]
Rodrigo Carvalho Auler
Virtual Machine Man

Membro desde: 14/02/2003 15:59:17
Mensagens: 576
Localização: Rio de Janeiro
Offline

Mais ou menos, do jeito que vc mostrou tem que ficar repetindo {T, T => int} cada vez que tiver que declarar a closure. Seria bom ter uma maneira de evitar essa repetição.

[]'s

Rodrigo Auler
 
Índice dos Fóruns » Assuntos gerais (Off-topic)
Ir para:   
Powered by JForum 2.1.8 © JForum Team