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

tnaires wrote:Bom, pra mim o que interessa é que agora a consistência das minhas coleções pode ser verificada em tempo de compilação, além de não ter que ficar fazendo casts o tempo todo.
Mas veja só, eu falando que a comunidade é exigente, nem tinha reparado que há uns posts atrás nesse tópico eu tava reclamando da sintaxe de closures também

O cast está lá, só que agora ele se esconde atrás de um <String> e mesmo com código "genérico" é possível causar ClassCastExceptions, simplesmente porque a implementação de genericos não existe, é uma coisa que está na imaginação dos programadores Java

Todas as propostas de reificação que eu vi em java quebram a compatibilidade por completo do código genérico atual e eu duvido muito que eles tenham interesse em fazer isso. Eles deveriam fazer igual a MicOsoft, admitir que a implementação é chula e escrever tudo denovo. Ou esquecer Java e começar a dar mais valor a outras linguagens da JVM, como Scala.

Do jeito que a coisa tá indo com o Java, só um pensamento vem a minha cabeça:

"Eu não sei com que IDEs o Java 8 será programado, mas o Java 9 será com paus e pedras."

Olá senhores,

Este recurso me lembra a execução de blocos de código que existe/existiam em clipper vrs. 5.x

Evidencia 1

Evidencia 2

Evidencia 3

Vou parar com as evidencias de utilização em clipper porque simples as formas de uso de blocos de códigos nesta linguagem deve beirar uma centena.

Me parece que na linguagem Ruby tem algo semelhante:

Pois bem, este recurso já existe fazem uns 15 ou 16 anos

Causou grande repercussão na linguagem clipper na época, pelo fato dela ser procedural e este recurso permitir a construção de algoritimos mais "sofisticados" e aumentando bastante o poder das estruturas dinamicas da linguagem.

O problema é que fazer a manutenção em algoritimos construidos com este recurso do tipo "sedutor" era dramático, porque o desenvolvedor geralmente aplicava isto como solução para tudo. Posso estar errado (e quero estar) mas muitos vão esquecer da OOP e aplicar isto na primeira dificuldade que aparecer.

Talvez este recurso se encaixe bem em linguagens como Ruby porque as propostas estão (IMO) bastante relacionadas, mas isto não diminui os possíveis problemas que podem ser causados por ele.

P.S. Com certeza isso irá fazer com que novos livros ou capitulos de livros sobre melhores práticas sejam editados enchendo ainda mais os bolsos de alguns.

flw

Forum Spammer Membro desde: 30/03/2008 20:56:41 Mensagens: 1293 Offline

renato3110 wrote:Porque em vez de ficar fazendo remendos eles não criam algo novo do zero?

E o que já está implementado? Fica pra lá?

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1706 Offline

Não, faz a mesma coisa que um espremedor com a laranja

JavaEvangelist Membro desde: 04/07/2007 18:28:58 Mensagens: 476 Offline

fantomas wrote:Olá senhores,

Este recurso me lembra a execução de blocos de código que existe/existiam em clipper vrs. 5.x

Evidencia 1
CLS ? EVAL( { | nVar | nVar * nVar }, 6 )

Evidencia 2
aVar := { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } bDouble := { | nVal | QOUT( TRANSFORM( ( nVal * 2 ), "@B 999")) } AEVAL( aVar, bDouble )

Evidencia 3
A := {'GARY HALL', 'FRED SMITH', 'TIM JONES'} B := { | X, Y | X > Y } asort(A, B)

Vou parar com as evidencias de utilização em clipper porque simples as formas de uso de blocos de códigos nesta linguagem deve beirar uma centena.

Me parece que na linguagem Ruby tem algo semelhante:
array = [1, 'hi', 3.14] array.each { |item| puts item }

Pois bem, este recurso já existe fazem uns 15 ou 16 anos

Causou grande repercussão na linguagem clipper na época, pelo fato dela ser procedural e este recurso permitir a construção de algoritimos mais "sofisticados" e aumentando bastante o poder das estruturas dinamicas da linguagem.

O problema é que fazer a manutenção em algoritimos construidos com este recurso do tipo "sedutor" era dramático, porque o desenvolvedor geralmente aplicava isto como solução para tudo. Posso estar errado (e quero estar) mas muitos vão esquecer da OOP e aplicar isto na primeira dificuldade que aparecer.

Talvez este recurso se encaixe bem em linguagens como Ruby porque as propostas estão (IMO) bastante relacionadas, mas isto não diminui os possíveis problemas que podem ser causados por ele.

P.S. Com certeza isso irá fazer com que novos livros ou capitulos de livros sobre melhores práticas sejam editados enchendo ainda mais os bolsos de alguns.

flw

Closure não é somente passagem de função de um lugar para outro! Uma função com suporte a closure captura o contexto onde foi criado. Coisa que em linguagens procedurais não acontecia (como: VB, Clipper, C) por uma razão simples: só haviam dois contextos, o local (dentro da função) e o global. E os dois eram sempre acessados onde quer que a função fosse executada.

Em linguagem OO, existe também o contexto do objeto. E com isso, não basta criar uma função e executá-lo por aí, é necessário que esta tenha a referência do objeto que a criou. Essa obtenção de referência, é o closure!

Veja mais em http://pt.wikipedia.org/wiki/Closure .

Maurício Linhares wrote:
A implementação de generics em java é sebosa e não existe informação nenhuma sobre os genéricos em tempo de execução, obrigando a construção de gambiarras (como passar o Class<T> quando você já passou T em algum lugar, não haver T[]). Uma feature que adiciona um absurdo de complexidade acidental, sem adicionar quase nada em funcionalidades. E a falta de type-inference faz o código generico ser desnecessariamente feio.

O motivo para não haver T[] é que arrays no java são covariant:

Para resolver esse problema use LIST, pois é invariant (só aceita mesmo tipo) e se haver algo errado nem deixa compilar.

Ou seja, isso pelo menos garante mais qualidade pro código. Eu não sei como conseguem implementar em outras linguagens estáticas o T[], a não ser que as arrays desde o começo fossem invriants, pq do contrário é improvável que admitam covariants em generics.

This message was edited 1 time. Last update was at 10/08/2008 21:20:01

cmoscoso wrote:E em Python, alguem ai?

Hmmm...

renato3110 wrote:Closure não é somente passagem de função de um lugar para outro! Uma função com suporte a closure captura o contexto onde foi criado. Coisa que em linguagens procedurais não acontecia (como: VB, Clipper, C) por uma razão simples: só haviam dois contextos, o local (dentro da função) e o global. E os dois eram sempre acessados onde quer que a função fosse executada.

Em linguagem OO, existe também o contexto do objeto. E com isso, não basta criar uma função e executá-lo por aí, é necessário que esta tenha a referência do objeto que a criou. Essa obtenção de referência, é o closure!

Veja mais em http://pt.wikipedia.org/wiki/Closure .

Valeu pelo esclarecimento...

Só quiz deixar claro que:

a) A idéia na minha opinião não é nova, como disse ela dever ter uns 15 anos e provavelmente o Turbo Pascal também já tinha coisa parecida (e melhor) 4 ou 5 anos antes disso, ou seja, 20 anos se não for mais rsrsrsrs.

b) Pelo fato do clipper ser procedural e java ser orientado a objetos e +15 anos terem se passado desde quando a ideia apareceu é claro que alguma coisa diferente tinha que ter.

c) Os códigos feitos com code blocks se transformaram em um inferno em termos de manutenção e conceito, e com os "closures", na minha opinião, não será diferente. Diria que será pior porque além dos BOLOVO teremos os closures para atormentar ainda mais

.

[]'s

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1706 Offline

Mas não fui eu quem disse aquilo

Ops! Foi mal

....me desculpe, foi o Leonardo3001.

JavaChild Membro desde: 03/06/2008 16:07:31 Mensagens: 103 Offline

Não sei se é um pouco precoce perguntar isto agora, mas e o groovy como fica? Pois dentre outras coisas ele tb possui closures. Será que estas funcionalidades "dinâmicas" na jdk vão matar o groovy?

fausto wrote:Não sei se é um pouco precoce perguntar isto agora, mas e o groovy como fica? Pois dentre outras coisas ele tb possui closures. Será que estas funcionalidades "dinâmicas" na jdk vão matar o groovy?

O Groovy fica no canto dele, sem nada a ver com a história. Nada muda.

Talvez melhorem o suporte e o conjunto de instruções da JVM, e com isso a performance de qualquer linguagem dinâmica na plataforma, mas só isso.

This message was edited 1 time. Last update was at 11/08/2008 09:01:59

[milésima mensagem.

]

Bem, desde a primeira vez que vi closures em java achei a sintaxe feia, confusa e cheia de pegadinhas e regras estranhas por debaixo dos panos (algo inerente da condição de ser uma feature tardia que obrigatoriamente teve que ser implementada com gambiarras na linguagem para não violar o backwards-compatible, a la generics).

Mas realmente, eu vi uma tendência de que closures virou modinha e tem muita gente tentando rubynizar o java usando closures só porque acha bonito, sem haver necessidade.

Há também um grande perigo na manutenção. Gambiarrizadores que produzem toneladas de código de péssima qualidade têm dificuldades com generics porque usá-los em lugar inadequado quase sempre resulta em erro de compilação, warning ou ClassCastException. Mas com closures é diferente: é possível utilizá-lo para fazer um goto dinâmico e destruir a manutenibilidade do código.

Ou seja, é um recurso poderoso e muito útil, mas também perigoso. Não deve ser usado a torto e a direito, senão vai trazer mais problemas do que resolver.

Isso eu achei interessante:

Sem o @Shared eu recebo um warning, nada mais do que justo!