%w(Akita On Rails) * 2.0 - Anatomia de Ruby Blocks/Closures Comments

Comment on 'Anatomia de Ruby Blocks/Closures' by daniel

2007-11-30T19:06:27Z

Fino Akita, finalmente entendi essa doidera… Sabia que não deveria ter dormido nas aulas de lisp e smalltalk na faculdade, a primeira vista é tudo esquisito para quem vem de linguagens derivadas do C++, depois começa a esclarecer.

Vlw por mais este artigo… já até imprimi para poder usar de consulta. hehehe.

Comment on 'Anatomia de Ruby Blocks/Closures' by AkitaOnRails

2007-11-30T16:02:33Z

Valeu Rodrigo, sabia que no meio de tanta coisa alguma coisa eu ia esquecer :-)

Comment on 'Anatomia de Ruby Blocks/Closures' by Rodrigo Kochenburger

2007-11-30T14:20:47Z

Ae akita!

Tenho alguns comentários. ;)

Em Ruby, uma closure/block são funções anônimas, e um proc é um objeto. Isso é o principal motivo para que o yield seja mais rápido do que capturar o bloco usando o argumento &block, já que a closure iria ter que ser “convertida” em um proc.

Outra coisa, existe sim uma maneira de ter um metodo livre do contexto de sua instancia. A classe Method possue um método chamado unbind, que retorna um UnboundMethod.

A class UnboundMethod não possui um método .call (ou outro para execução), mas possui um método .bind, que pode ser usado para “ajustar” o contexto do método para uma determinada instancia, e então posteriormente ser executado.

Ah, e mais uma coisa. Na versão 1.8, os construtores proc e lambda são sinônimos e Proc.new é um pouco diferente. Na versão 1.9, proc passou a ser um sinônimo para Proc.new e lambda vai manter o comportamento existente.

http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l46

Quando eu comecei com Ruby, lembro que Block/Closures e Symbols eram as coisas mais estranhas que eu ja tinha visto.

Muito bom os artigos sobre ambos assuntos.

Bom, Eras isso!

Comment on 'Anatomia de Ruby Blocks/Closures' by AkitaOnRails

2007-11-30T14:15:45Z

Afe, não vá por esse caminho :-) Esse assunto já foi discutido aqui ad nauseam, e em resumo eu particularmente prefiro não dizer “Ruby é 100% OOP”, mas simplesmente “Ruby é bastante OOP”. E para mim isso é suficiente.

Por isso que no começo eu coloco as ‘letras miúdas’ ...

Matz criou Ruby para agradar a ele mesmo. DHH criou Rails para agradar a si próprio. Quem dividir das mesmas opiniões irá gostar de Ruby e Rails, mas do contrário sempre haverá essa discussão e no fim da linha o que vemos é que isso é irrelevante.

Se Ruby fosse 100% OOP ele seria Smalltalk. Ruby é o que é, e gostamos dela por ser assim mesmo. Espero que ela não mude muito no futuro.

Comment on 'Anatomia de Ruby Blocks/Closures' by Stan

2007-11-30T13:52:13Z

Olá. Parabens pelo blog! Muito bom… Estou sempre acompanhando (embora este seja meu primeiro comentário). Não manjo muito de ruby (ainda) e pode parecer besta, mas discordo quando você diz que Ruby é 100% OO. Além de blocos, existem uma infinidade de outras coisas em Ruby que não são OO. São coisas que as vezes podem até facilitar o desenvolvimento, mas que “quebra” a ideia de que Ruby é 100% OO!

Exemplos simples… IF, ELSE, FOR, WHILE… são comandos que executão ações, mas não são mensagens… Em smalltalk por exemplo, esses comandos não existem, sendo substituidos por métodos.

Em ruby:

if a 10 print "lalala" end

Isso é totalmente procedural. Não tem nenhuma mensagem ai. Já em smalltalk, o mesmo codigo seria:

(a 10) ifTrue: [ ‘lalala’ out. ].

Entendo que o autor fez isso para “facilitar” o aprendizado, mas como disse, não da pra dizer que isso é 100% OO (na minha opinião).

[]´s!