Uso do yield

What is classpath? Membro desde: 01/07/2009 11:03:35 Mensagens: 6 Offline

Boa noite caros, estou começando a programar em Ruby agora e logo de início dei de cara com o comando yield, li a respeito, fiz alguns teste e entendi bem a sua funcionalidade, mas a minha grande dúvida está relacionada a sua verdadeira utilidade, vocês conseguiriam me dar exemplos mais complexos dos que existem por aí em qualquer artigo sobre yield? Até agora, todos os exemplos que eu vi poderiam simplesmente ser trocados para um método ou um bloco diretamente dentro do método.

This message was edited 2 times. Last update was at 03/12/2011 09:18:58

Alguns métodos interessantes que usam blocos (yields) sem ser os clássicos das collections

Tudo que tiver dentro do bloco acima vai rodar em uma única transação, que no início é aberta e no final commitada, se ocorrer exceção dentro do bloco ele faz rollback

O arquivo é aberto e fechado automaticamente, evitando os try / catch / finally horríveis de Java que sempre acaba alguém esquecendo de fechar

Ex de DSL do Rails para configurar rotas REST aninhadas

This message was edited 1 time. Last update was at 04/12/2011 12:37:40

Como vai DiegoCC? Que legal que está estudando Ruby cara! Manda ver.

Bom, realmente o yield não é tecnologia alienígena e certamente será sempre possível substituí-lo por cosias "normais" (por assim dizer, não me entenda mal).
Mas o que acho legal nele é a legibilidade e facilidade que dá para implementar certas coisas. Veja por exemplo a seguinte funcionalidade implementada com o uso do yield tirada do projeto standalone_migrations.

Esse código permite a alteração das configurações internas de um projeto (não importa pro exemplo saber exatamente o que está acontencendo) em tempo de execução. Quem implementou a api não sabe quais configurações serão utilizadas em tempo de execução, nem sequer quem está usando a api. Mas a forma como isso foi implementado permite ao usuário da api deixar para descobrir essas configurações somente em tempo de execução e ainda assim realizar alguma alteração. Veja um exemplo um pouco mais concreto, que foi na verdade a principal motivação dessa implementação, que é alterar as configurações de banco de dados de projetos hosteados pelo heorku:

E finalmente o trecho de implementação onde o yield é realmente invocado:

fonte: https://github.com/thuss/standalone-migrations/blob/master/lib/standalone_migrations/configurator.rb

No fim das contas o grande valor adicionado aqui pelo yield foi a forma como ficou limpo/fácil adiar para o último momento (execução em host específico) a decisão sobre qual configuração será usada para conexão com o banco de dados.

Que achou desse uso DiegoCC, espero ter ajudado e vamos discutir a respeito! =)

What is classpath? Membro desde: 01/07/2009 11:03:35 Mensagens: 6 Offline

Fala ricardo.valeriano, vamos ver se eu entendi bem. O exemplo do código que você passou serve para passar a configuração do banco para o módulo/library/whatever sem que seja preciso em algum momento invocar um arquivo de configuração para obter esses dados, certo?

Se for isso mesmo, eu consegui captar bem a utilidade dele e digo mais, achei genial essa implementação! Eu venho do PHP e por mais modular que façamos os códigos sempre temos o hábito de dar requires em arquivos de configuração (mesmo que seja indiretamente por um ponto padrão de algum framework).

Obrigadão pela respostas ricardo.valeriano e o victorcosta.

com esse exemplo que o Valeriano deu, você ainda pode adicionar um outro ambiente de config sem se preocupar com a implementação da config:

E em tempo de execução, os blocos iriam ser executados dependendo do environment.
Talvez estaria aí a maior importância do yield Tou certo?

Thread.start() Membro desde: 28/07/2006 15:31:30 Mensagens: 37 Offline

Fala @leandronsp, belezinha man?

Então, faz sentido sim a sua conclusão. É que nesse caso específicamente (pelo menos até onde sei) só há o postgre disponível lá no Heroku, mas como eu disse, faz sentido.

@DiegoCC, o que eu realmente queria destacar com esse exemplo é a possibilidade que o uso de um bloco oferece de delegar parte do comportamento da aplicação para mais tarde. Nesse caso, quem escreveu o standalone_migrations não precisa saber todas as possibilidades possíveis de configuração relacionadas com a aplicação em tempo de execução, mas apenas se preocupar em criar um "ponto de extensão" por assim dizer. Quem quiser aumentar/adaptar/melhorar o funcionamento, precisa plugar um bloco a esse ponto de extensão, e através dele adicionar a funcionalidade desejada.

Notícias, artigos e o maior fórum brasileiro sobre Java