�ltimas mensagens do t�pico "Monkeypatching is Destroying Ruby"

Monkeypatching is Destroying Ruby

pcalcado — GMT

[quote][...] To the point that smart, experienced hackers reach for a monkey patch as their tool of first resort, even when a simpler, more traditional solution is possible.

I don?t believe this situation to be sustainable. Where I work, we are already seeing subtle, difficult-to-debug problems crop up as the result of monkey patching in plugins. Patches interact in unpredictable, combinatoric ways. And by their nature, bugs caused by monkey patches are more difficult to track down than those introduced by more traditional classes and methods. As just one example: on one project, it was a known caveat that we could not rely on class inheritable attributes as provided by ActiveSupport. No one knew why. Every Model we wrote had to use awkward workarounds. Eventually we tracked it down in a plugin that generated admin consoles. It was overwriting Class.inherited(). It took us months to find this out.[/quote]

http://avdi.org/devblog/2008/02/23/why-monkeypatching-is-destroying-ruby/

Eu acho que monkey patching � algo abusado em Ruby. O problema � que o esquema de bindings em Ruby � muito ruim, voc� n�o tem como criar blocos de escopo arbitr�rios ou fazer como em Scala e limitar o escopo de um patch. Eu j� tive problemas s�rios com 1.minute e conflito entre patches.

Re:Monkeypatching is Destroying Ruby

faq — GMT

O pessoal do zope/plone � um �timo exemplo de onde monkey patching pode levar. Na minha opni�o utilizar isso � pr�tica ruim e detona n�o s� ruby mas qualque linguagem que suporte isso.

Re:Monkeypatching is Destroying Ruby

cv — GMT

[quote=faq]O pessoal do zope/plone � um �timo exemplo de onde monkey patching pode levar. Na minha opni�o utilizar isso � pr�tica ruim e detona n�o s� ruby mas qualque linguagem que suporte isso.[/quote]

Sei la, eu acho a alternativa bem pior.

Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

Mas qual seria a alternativa?

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Em Ruby n�o d� para fazer muito. Voc� bsicamente pode usar monkey patching para alterar as classes core ou fazer algo no estilo Java onde voc� tem uma ger�ncia de depend�ncias est�ticas, onde um inteiro n�o pode ser independente de Date em compile time e integrado em runtime.

O problema � que as reras de escopo em Ruby s�o arcaicas considerando as capacidades de metaprograma��o da linguagem. Tudo � muito global e muito irrevers�vel.

Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

Algo como cflow e cflowbelow do AspectJ j� me deixariam feliz

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Scala tem uma �tima sa�da para isso, com convers�es impl�citas, e Lisp tem bloco l�xicos hier�rquicos com LET h� d�cadas. Acho que simplesmente ningu'm pensou que ia precisar disso e como consequ�ncia voc� tem monkey patching e namespace wars.

Re:Monkeypatching is Destroying Ruby

louds — GMT

Ruby tem duas coisas que melam a vida de quem quer fazer metaprograma��o mais hardcode. N�o existe como sobrescrever o mecanismo de resolu��o de nomes e t�o pouco como definir escopos no qual altera��es a classes acontecem.

Re:Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=louds]Ruby tem duas coisas que melam a vida de quem quer fazer metaprograma��o mais hardcode. N�o existe como sobrescrever o mecanismo de resolu��o de nomes e t�o pouco como definir escopos no qual altera��es a classes acontecem.[/quote]

A/C

Louds (Moderador GUJ)

Por gentileza, conforme sua explica��o, postei a URL abaixo, porque n�o compreendi tais afirma��es sobre Ruby metaprograma��o, o que voc� quer dizer sobre [b]mais hardcode[/b], [b]mecanismo de resolu��o de nomes , etc ...

Poderia finalizar colocando melhor transpar�ncia ao assunto, sitando melhores detalhes sobre tal concep��o.[/b]

[url]http://www.guj.com.br/posts/list/83661.java[/url]

Att.
Marcio Duran

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Simples, crocodilo, como voc� faz e quiser definir um m�todo seu, que voc� criou e faz algo que s� voc� precisa, chamado "times" em Fixnum se voc� usa Rails?

Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=pcalcado]voc� n�o tem como criar blocos de escopo arbitr�rios[/quote]
intance_eval tem resolvido bem a minha vida:
[code]
def ei_vc(&bloco)
MeuEscopo.new.instance_eval(&bloco)
end

ei_vc do
qualquer
coisa
end

class MeuEscopo
def qualquer
# ...
end
def coisa
# ...
end
# ...
end
[/code]

Re:Monkeypatching is Destroying Ruby

thingol — GMT

[quote=Marcio Duran][quote=louds]Ruby tem duas coisas que melam a vida de quem quer fazer metaprograma��o mais hardcode. N�o existe como sobrescrever o mecanismo de resolu��o de nomes e t�o pouco como definir escopos no qual altera��es a classes acontecem.[/quote]
A/C
Louds (Moderador GUJ)
Por gentileza, conforme sua explica��o, postei a URL abaixo, porque n�o compreendi tais afirma��es sobre Ruby metaprograma��o,[/quote]

O Louds est� falando em um n�vel que � umas duas ordens de grandeza maiores que voc� pode compreender. Se quiser entender melhor o que ele fala, por favor, sr. Duran, aprenda outras linguagens de programa��o e um bocadinho de matem�tica, para que voc� n�o reduza Ruby a uma mera "linguagem orientada a objetos", com voc� postou aqui no GUJ

E leia um pouco mais - [url=http://pt.wikipedia.org/wiki/Sitar]sitar[/url] � um instrumento musical de origem �rabe; acredito que voc� queria dizer "citar".
[img]http://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Sitar_1.gif/200px-Sitar_1.gif[/img]

Re:Monkeypatching is Destroying Ruby

louds — GMT

[jaba mode on]
Meu coment�rio sobre isso ficou muito grande e acabei colocando ele no meu blog
[url]http://www.kumpera.net/blog/index.php/2008/03/03/monkeypatching-gambiarra-du-jour/[/url]
[jaba mode off]

Monkeypatching is Destroying Ruby

pcalcado — GMT

[quote=Fabio Kung][quote=pcalcado]voc� n�o tem como criar blocos de escopo arbitr�rios[/quote]
intance_eval tem resolvido bem a minha vida:
[/quote]

Aind an�o adianta. Em outro t�pico eu citei uma DSL de testes usando RSpec e Selenium, nessa DSL tivemos que azer os objetos de dom�nio inclu�rem m�dulos do RSpec para que pud�ssemos usar pending e outros m�todos dentro dos nossos blocos que n�o s�o closures.

Ruby precisava ter bindings hier�rquicos. Hoje em Ruby voc� so consegue avaliar algo em dois n�veis, o primeiro (como intance_eval) e o Object/Kernel.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

e vc n�o consegue fazer isso decorando os caras s� no escopo do bloco?

algo como o jmock faz em java:
[code]
{
one(obj).pending()...
}
[/code]
Tudo bem, pode dar uma trabalheira, mas acho que funciona.

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Desculpa, F�bio, boiei. Decorando o que?

Monkeypatching is Destroying Ruby

louds — GMT

[quote=pcalcado][quote=Fabio Kung][quote=pcalcado]voc� n�o tem como criar blocos de escopo arbitr�rios[/quote]
intance_eval tem resolvido bem a minha vida:
[/quote]

Aind an�o adianta. Em outro t�pico eu citei uma DSL de testes usando RSpec e Selenium, nessa DSL tivemos que azer os objetos de dom�nio inclu�rem m�dulos do RSpec para que pud�ssemos usar pending e outros m�todos dentro dos nossos blocos que n�o s�o closures.

Ruby precisava ter bindings hier�rquicos. Hoje em Ruby voc� so consegue avaliar algo em dois n�veis, o primeiro (como intance_eval) e o Object/Kernel.[/quote]

N�o precisa ter binding hier�rquico, basta ter binding extens�vel.

[code]
code = proc {|a| print a.d }

context_eval(proc) do |obj, name|
return "d � mais legal" if name == :d
obj.send (name)
end
[/code]

Com isso � trivial implementar instance_eval module_eval e por ai vai. Para completar permita configurar um bloco padr�o de resolu��o por Modulo/classe/m�todo e adicione a possibilidade de andar na pilha e recuperar um bloco que resolva nomes de acordo com o m�todo em quest�o. Com essas tr�s coisas basicamente tudo que reclamam sobre meta-programa��o em Ruby tem solu��o simples.

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Exemplo do problema:

[code]
class A

def bazooka
@a = "BOOOOM"
B.new.fire {puts @a}
end
end

class B

def fire(&block)
instance_eval &block
end

end

A.new.bazooka #boom?
[/code]

Monkeypatching is Destroying Ruby

pcalcado — GMT

[quote=louds]N�o precisa ter binding hier�rquico, basta ter binding extens�vel.[/quote]

Eu diria que n�o precisava ter binding extens�vel, bastava ter binding hier�rquico que � mais limitado, provavelmente mais f�cil de implementar e ainda assim eficiente na maioria dos casos.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=pcalcado]Desculpa, F�bio, boiei. Decorando o que?[/quote]
Eu acho que eu to boiando. Pensei numas coisas doidas aqui, mas s� consigo explicar direito vendo o que vc quer fazer.

Procurei o seu t�pico da selenium dsl (e pending) e n�o achei (link?). Posta um snippet?

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Aqui:

http://www.guj.com.br/posts/list/45/83613

O m�todo 'On do {stuff}'faz um instance_eval. azendo isso ele perde o contexto do bloco describe do RSpec, perdendo ent�o o acesso ao m'todo pending().Como pending e stateless a coisa foi resolvida fazendo o cara que implementa o m�todo on() incluir o m�dulo que declara pending. Uma bela gambiarra

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=louds]Ruby tem duas coisas que melam a vida de quem quer fazer metaprograma��o mais hardcode. N�o existe como sobrescrever o mecanismo de resolu��o de nomes e t�o pouco como definir escopos no qual altera��es a classes acontecem.[/quote]
louds, vc t� cheio de fans:

http://forum.rubyonbr.org/forums/1/topics/2783
http://forum.rubyonbr.org/forums/1/topics/2766

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Oi, gente,

Eu t� discutindo l� no outro f�rum e esse menino falou isso. Ser� que voc�s podem me audar a responder ele? Sabe, ele fica me sacaneando e eu quero dar o troco...

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=pcalcado]Aqui:

http://www.guj.com.br/posts/list/45/83613.java#446292

O m�todo 'On do {stuff}'faz um instance_eval. azendo isso ele perde o contexto do bloco describe do RSpec, perdendo ent�o o acesso ao m'todo pending().Como pending e stateless a coisa foi resolvida fazendo o cara que implementa o m�todo on() incluir o m�dulo que declara pending. Uma bela gambiarra :P [/quote]

T�, agora entendi. Que tal algo do tipo:
[code]
module SeleniumOperations
def search_for() ... end
def filter_by() ... end
end

def on(pagina, &stuff)
extend SeleniumOperations
instance_eval(&stuff)
end
[/code]

Isso n�o cria o escopo novo e acho que resolveria o seu problema. S� acho que n�o ataca o problema maior que eu ainda n�o consegui capturar de voc�! ;)

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Soluciona o problema porque voc� et� usando fun��es apenas, n�o objetos. Que tal:

[code]
class A
def initialize
@abc =122
end

def hehe
B.new.huhuhu {p @abc; p bwawawawawa}
end
end

class B
def huhuhu(&block)
instance_eval &block
end

def bwawawawawa
'risada maquiavelica'
end
end

A.new.hehehe
[/code]

Eu quero que meu bloco tenha acesso ao escopo de B para poder usar o metodo bwawawawawa() mas ao mesmo tempo tenha acesso ao escopo original, para poder acessar @abc (ou um �todo que retorne abc, tanto faz).

Se n�o fosse por A ter estado eu poderia incluir B em A, o que seria gambiarra mas funcionaria e � o que fizemos com selenium. Este tipo de situa��o surge o tempo todo com [url=http://fragmental.tw/research-on-dsls/domain-specific-languages-dsls/internal-dsls/]internal DSLs[/url].

Re:Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=thingol]
O Louds est� falando em um n�vel que � umas duas ordens de grandeza maiores que voc� pode compreender. Se quiser entender melhor o que ele fala, por favor, sr. Duran, aprenda outras linguagens de programa��o e um bocadinho de matem�tica, para que voc� n�o reduza Ruby a uma mera "linguagem orientada a objetos", com voc� postou aqui no GUJ

E leia um pouco mais - [url=http://pt.wikipedia.org/wiki/Sitar]sitar[/url] � um instrumento musical de origem �rabe; acredito que voc� queria dizer "citar".
[img]http://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Sitar_1.gif/200px-Sitar_1.gif[/img]

[/quote]

Presta aten��o nas respostas e perguntas aqui sendo feitas, e tenta aprender alguma coisa que n�o seja uma cegueira de falta do seu conhecimento, que j� vem se passando despercebido.Outra coisa use mensagens privadas para falar sobre mim, isso � mais apropriado, � por isso que o GUJ tem esse recurso.Aqui o assunto � Ruby.
Outra coisa as pessoas sabem se representar, n�o precisam de segunda voz.
"Em rela��o a citar e sitar, pra um ignorante como voc� tudo passa ser uma coisa s� "

Re:Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

[quote=Marcio Duran]... falta do seu conhecimento que j� vem se passando despercebido.Outra coisa use mensagens privadas para falar sobre mim, isso � mais apropriado, e por isso que o GUJ tem esse recurso.Aqui o assunto � Ruby[/quote]

Ainda bem que a "falta de conhecimento" do thingol "j� vem se passando despercebido", porque se algu�m percebesse que ele n�o tem conhecimento em alguma coisa, de certo � algo que estava escondido nos confins do universo

Re:Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=Maur�cio Linhares]
confins do universo [/quote]

Voc� bem que podia ficar l�, o assunto aqui � Ruby.

Re:Monkeypatching is Destroying Ruby

tnaires — GMT

U�, onde est� essa mensagem que o Marcio Duran se referiu?

Re:Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=tnaires]U�, onde est� essa mensagem que o Marcio Duran se referiu?[/quote]

"Acho n�o caiu a ficha em voc�"

Monkeypatching is Destroying Ruby

Daniel Quirino Oliveira — GMT

M�rcio, por favor, n�o desvie o assunto do t�pico. Se voc� tiver alguma coisa a acrescentar de �til a este t�pico, por favor, fa�a-o. Caso contr�rio, evite postar mensagens fora do assunto central do t�pico. Como voc� mesmo disse, existem mensagens privadas para isso. Assunto encerrado.

Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=Daniel Quirino Oliveira]M�rcio, por favor, n�o desvie o assunto do t�pico. Se voc� tiver alguma coisa a acrescentar de �til a este t�pico, por favor, fa�a-o. Caso contr�rio, evite postar mensagens fora do assunto central do t�pico. Como voc� mesmo disse, existem mensagens privadas para isso. Assunto encerrado.[/quote]

Pe�o a genteliza de passar essa mensagem aos demais que est�o fazendo-o tamanha bossalidade e simplesmente vem de faixada aqui, e que n�o est�o explorando o assunto.

Como disse questionei, o Louds por suas afirma��es todavia as mesmas est�o sendo questionadas aqui, n�o tomo partido por ninguem e eu espero que voc� fa�a o mesmo.

Att.
Marcio Duran

Monkeypatching is Destroying Ruby

nbluis — GMT

Voltando ao t�pico.

Marcio Duran, o que voc� n�o entendeu mesmo ?
Tem tantas referencias ali que j� n�o sei mais.

Sobre metaprograma��o , resolu��o de nomes ?

Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=nbluis]Voltando ao t�pico.

Marcio Duran, o que voc� n�o entendeu mesmo ?
Tem tantas referencias ali que j� n�o sei mais.

Sobre metaprograma��o , resolu��o de nomes ?[/quote]

Veja a afirma��o do Louds sobre Escopo..., n�o entendi...

Re:Monkeypatching is Destroying Ruby

louds — GMT

[quote=pcalcado]

Eu quero que meu bloco tenha acesso ao escopo de B para poder usar o metodo bwawawawawa() mas ao mesmo tempo tenha acesso ao escopo original, para poder acessar @abc (ou um �todo que retorne abc, tanto faz).

Se n�o fosse por A ter estado eu poderia incluir B em A, o que seria gambiarra mas funcionaria e � o que fizemos com selenium. Este tipo de situa��o surge o tempo todo com DSLs.[/quote]

Uma d�vida, se voc� casar um par de instance eval/ module_eval para instancias de definem apenas os *_missing n�o � possivel capturar todos bindings?

Monkeypatching is Destroying Ruby

nbluis — GMT

[quote=Marcio Duran]
Veja a afirma��o do Louds sobre Escopo..., n�o entendi...[/quote]

Isso � exatamente o que est� sendo discutido no t�pico.
Este t�pico tem um assunto mais complexo do que se est� acostumado por ai.

Falam sobre o escopo de blocos dentro de ruby. Veja os exemplos do shoes que est�o bem esplicados.

E inclusive a impossibilidade de limitar escopo de altera��es feitas no core da linguagem possibilitada pelas classes abertas.

O [url=http://www.kumpera.net/blog/index.php/2008/03/03/monkeypatching-gambiarra-du-jour/]post do louds sobre monkeypatching[/url] ficou bem legal.
D� uma lida al�.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=pcalcado]Soluciona o problema porque voc� et� usando fun��es apenas, n�o objetos. Que tal:

[code]
class A
def initialize
@abc =122
end

def hehe
B.new.huhuhu {p @abc; p bwawawawawa}
end
end

class B
def huhuhu(&block)
instance_eval &block
end

def bwawawawawa
'risada maquiavelica'
end
end

A.new.hehehe
[/code]

Eu quero que meu bloco tenha acesso ao escopo de B para poder usar o metodo bwawawawawa() mas ao mesmo tempo tenha acesso ao escopo original, para poder acessar @abc (ou um �todo que retorne abc, tanto faz).

Se n�o fosse por A ter estado eu poderia incluir B em A, o que seria gambiarra mas funcionaria e � o que fizemos com selenium. Este tipo de situa��o surge o tempo todo com DSLs.[/quote]

Emulemos ent�o o binding hier�rquico!
[code]
class A
def pele
"aaabbbbccc"
end

def hehe
B.new.huhuhu(self) {p pele; p bwawawawawa}
end
end

class B
def huhuhu(parent_context, &block)
(class << self; self; end).send(:define_method, :method_missing) do |method, *args|
parent_context.send(method, *args)
end
instance_eval &block
end

def bwawawawawa
'risada maquiavelica'
end
end

A.new.hehe
[/code]
Agoro Ruby, e adoro metaprograma��o! :twisted:

Re:Monkeypatching is Destroying Ruby

louds — GMT

[quote=Fabio Kung]
Emulemos ent�o o binding hier�rquico!
[code]
class A
def pele
"aaabbbbccc"
end

def hehe
B.new.huhuhu(self) {p pele; p bwawawawawa}
end
end

class B
def huhuhu(parent_context, &block)
(class << self; self; end).send(:define_method, :method_missing) do |method, *args|
parent_context.send(method, *args)
end
instance_eval &block
end

def bwawawawawa
'risada maquiavelica'
end
end

A.new.hehe
[/code]
Agoro Ruby, e adoro metaprograma��o! :twisted:

[/quote]

Voc� t� simulando heran�a aqui, n�o binding hier�rquico.

Re:Monkeypatching is Destroying Ruby

nbluis — GMT

[quote=louds]

Voc� t� simulando heran�a aqui, n�o binding hier�rquico.[/quote]

Isso � bastante usado em javascript para fornecer heran�a.

Prototype � um exemplo disso.

Re:Monkeypatching is Destroying Ruby

thingol — GMT

Bom, vou voltar aqui que a poeira abaixou, e vou fazer minhas declara��es:

- Eu n�o sei Ruby;
- Entretanto, eu sei o que � metaprograma��o e problemas de scoping e outros quetais;
- E vou fazer minha digress�o aqui.

H� dois tipos de programadores: os "blue-collars" e os "white-collars". *
O sr. Gosling tinha afirmado uma vez que Java era para os programadores "blue-collar", ou seja, aqueles caras que antigamente se matavam para fazer os programas em C++ funcionarem, e agora se matam para fazer os programadores Java funcionarem no mundo real - deploys, web services e outras chatea��es. Eles n�o t�m muitas id�ias de conceitos abstratos, e � uma vit�ria que eles finalmente consigam entender corretamente o conceito de orienta��o a objeto, que levou muitas d�cadas para ser aceito.
Os "white-collars" s�o aqueles que entendem todos esses conceitos e criam novos, ou pelo menos t�m a coragem de irem al�m desses conceitos. Programa��o funcional ou gen�rica para eles � o seu caf� da manh�, e � coisa muito antiga para eles - afinal de contas, quantos 50 anos tem a linguagem Lisp? Normalmente s�o os que falam de assuntos "esot�ricos".

O sr. Marcio Duran (um cl�ssico "blue-collar" - eles � que fazem o mundo girar) entrou no meio de uma discuss�o de "white-collars" e esperou tentar entender alguma coisa rapidamente**, s� que n�o percebeu que "entrou na sala errada" e exigiu ser tratado como um igual. A� � que ocorreu o problema.

---------

* N�o estou usando aqui "white-collar" no sentido em que se d� nas editorias de pol�tica, que tratam de muitos "crimes de colarinho branco". Nada disso - uso em contraposi��o a "blue-collar", que � o colarinho de um macac�o azul de um oper�rio de f�brica.
** Como bom "blue-collar", ele n�o tem tempo de tentar entender essas coisas "esot�ricas" e acha tudo uma grande besteira.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=louds]Voc� t� simulando heran�a aqui, n�o binding hier�rquico.[/quote]
Tem raz�o, mas nesse caso o efeito � o mesmo, certo?

E de qualquer forma, prefiro mesmo "simular heran�a" com delega��o do que usar heran�a de verdade.

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

[quote=louds]Uma d�vida, se voc� casar um par de instance eval/ module_eval para instancias de definem apenas os *_missing n�o � possivel capturar todos bindings?[/quote]

� basicamente o que venho utilizando hoje para contornar. O problema � que preciso avaliar em elo menos 3 bindings: do closure, da classe que recebe o closure e top-level. Conseguir o primeiro � complicado, a menos qu voc� fa�a a gambi que o Kung posto de passar self no m�todo

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

gambi essa minha que � melhor que a gambi de incluir o modulo!

Re:Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

Tem algum jeito de pegar o call stack atual em Ruby como tem em Java?

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

[quote=Fabio Kung]gambi essa minha que � melhor que a gambi de incluir o modulo! [/quote]

Estamos discutindo qual gamiarra � melhor

CQD

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=Maur�cio Linhares]Tem algum jeito de pegar o call stack atual em Ruby como tem em Java?[/quote]
Tem isso, mas n�o serve:
http://ruby-doc.org/core/classes/Kernel.html#M005955

Do jeito que voc� quer n�o conhe�o...

Re:Monkeypatching is Destroying Ruby

Marcio Duran — GMT

[quote=thingol]
O sr. Marcio Duran (um cl�ssico "blue-collar" - eles � que fazem o mundo girar) entrou no meio de uma discuss�o de "white-collars" e esperou tentar entender alguma coisa rapidamente**, s� que n�o percebeu que "entrou na sala errada" e exigiu ser tratado como um igual. A� � que ocorreu o problema.
[/quote]

O assunto continua sendo Ruby, mas posso dizer que voc� tem tamanha imagina��o para canditado a [b]"blue-collar".
[/b]
"Em rela��o a querer aprender ou ter conhecimento isso vai da vontade e busca da investiga��o ao saber de cada um"

[b]"Apostila Ruby on Rails fique avontade para abrir sua mente"[/b]

[b]Ruby on Rails[/b]

[url]http://linorg.ciagri.usp.br/ftp/pub/webdev/rails-tutorial.pdf[/url]

Re:Monkeypatching is Destroying Ruby

louds — GMT

[quote=Fabio Kung][quote=Maur�cio Linhares]Tem algum jeito de pegar o call stack atual em Ruby como tem em Java?[/quote]
Tem isso, mas n�o serve:
http://ruby-doc.org/core/classes/Kernel.html#M005955

Do jeito que voc� quer n�o conhe�o...[/quote]

O povo do rubinius tava fazendo algo no sentido de permitir stack walk arbitr�rio, sendo poss�vel N�o sei se � poss�vel capturar com contexto de um frame, entretanto.

Re:Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

Re:Monkeypatching is Destroying Ruby

TheMask — GMT

Gujeiros,

ser� que voc�s poderiam citar refer�ncias bibliogr�ficas para entendermos esse papo todo? N�o, n�o quero nenhum livro dos Deitel. E nem precisa ser um Head First Metaprogramming. Pode mandar algo mais bizarro.

Acabei de me avaliar como white-and-yellow-collar!

Re:Monkeypatching is Destroying Ruby

louds — GMT

[quote=TheMask]Gujeiros,

ser� que voc�s poderiam citar refer�ncias bibliogr�ficas para entendermos esse papo todo? N�o, n�o quero nenhum livro dos Deitel. E nem precisa ser um Head First Metaprogramming. Pode mandar algo mais bizarro.

Acabei de me avaliar como white-and-yellow-collar! [/quote]

Procure pelo assunto no lambda the ultimate e no citeseer. Boa leitura.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=TheMask]Gujeiros,

ser� que voc�s poderiam citar refer�ncias bibliogr�ficas para entendermos esse papo todo? N�o, n�o quero nenhum livro dos Deitel. E nem precisa ser um Head First Metaprogramming. Pode mandar algo mais bizarro.

Acabei de me avaliar como white-and-yellow-collar! [/quote]
Ruby for Rails do David Black tamb�m � uma boa leitura e aborda coisas interessantes sobre metaprograma��o aplicada no rails.

Re:Monkeypatching is Destroying Ruby

moises.trovo — GMT

Eu ainda n�o entendi direito o que voc� est� tentando fazer, vc procura algo como se os contextos fossem se sobrepondo numa pilha ou uma "heran�a de escopo", mas ainda n�o entendi o que isso tem a ver com monkey patching.
O que eu pensei foi em passar o contexto que tem o m�todo que vc qr acessar por vari�vel.

[code]class A
def initialize
@abc =122
end

def hehe
B.new.huhuhu {|context| p @abc; puts context.bwawawawawa}
end
end

class B
def huhuhu(&block)
yield self
end

def bwawawawawa
'risada maquiavelica'
end
end

A.new.hehe
[/code]

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

O seu exemplo � basicamente aq mesma coisa do do Kung, com a dire��o invertida. Ainda � uma gambiarra e apesar de solucionar o exemplo (1)cria ainda mais sintaxe acidental e (2)n�o resolve todos os casos, e se eu quiser ter tr�s n�veis? N�veis arbitr�rios? A pergunta �: como resolver isso sem mexer no bloco nem na invocac�o do m�todo?

O problema � que se eu n�o tenho mecanismo de binding decente eu crio muitos m�todos em classes existentes, como no caso que citei do Selenium onde uma classe de dom�nio teve que incluir um m�dulo do SeleniumRC. No fim do dia voc� acaba tendo m�todos em Fixnum que � s�o usados em um canto escuso de uma biblioteca que voc� importou. Um bom exemplo � o problema que o RSpec cria aodefinir m�todos em Object. Se fosse poss�vel definir m�todos apenas dentro do bloco it() ele n�o precisaria poluir todo o namespace com metodos que s� fazem sentido nele.

Com a �nfase em DSLs em Ruby pode-se esperar ainda mais olui��o, cada DSL implementa sua gambiarra para ter uma sintaxe diferenciada e no final seu Fixnum vai estar assoviando, chupando cana e se chamando Roberta Close.

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

Phillip, que tal colocar as opera��es que vc quer adicionar nas classes (limitando o escopo) em um m�dulo e sobrescrever o append_features (http://ruby-doc.org/core/classes/Module.html#M001659):

[code]
module DSLExtensions
def ... end
def append_features(mod)
#guarda as modificacoes em algum lugar para desfazer depois!
end
end

def novo_escopo(&blk)
Fixnum.send(:include, DSLExtensions)
instance_eval(&blk)
remove_extensions_from(Fixnum)
end
[/code]

Gambi forte. N�o sei se � pior que passar o contexto pai como vari�vel...

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

E eu fa�o a mesma besteira que o Rails faz e fico com uma thread s�?

Nah, a outra gambiarra pelo menos era tread-safe

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

�, mas a outra tb n�o resolve o problema do "scoped monkey patching"!

[code]
operacao do
1.so_pode_ter_esse_metodo_aqui
end
[/code]

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

(e acabaram as minhas id�ias)

(por enquanto)

A conclus�o � que se eu tivesse a solu��o para isso, j� estaria t�o famoso quanto o Phillip!

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

S�o dois problemas. Um � a falta de op��es de binding, fazendo com que eu tenha quea alterar classes (adicionar m�todos em inteiros) quando o que eu queria era simplesmente que um m�todo estivesse disponivel em um contexto qualquer. Outro � o fato de que se eu alterar uma classe (como consequ�ncia do primeiro ou n�o) eu altero ela em todo o sistemas.

Ser� que JRuby n�o consegue resolver o seundo problema com classloaders diferentes? N�o tenho id�ia, n�o sei como o JRuby funciona... LOOOOOOOOOOOOOOUUUUUDS!!!

Re:Monkeypatching is Destroying Ruby

louds — GMT

Re:Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

[quote=louds]Acho que usando 2 instancias, uma para a aplica��o e outra para a DSL, com call by value, iow serializa todos argumentos, provavelmente funciona.[/quote]

Sou f� desse bixo

De qualquer forma, n�o daria conflito de classloaders ter e usar a mesma classe duas vezes no mesmo lugar n�o?

Normalmente quando voc� carrega a mesma classe por dois classloaders e tenta fazer uma atribui��o j� pega uma CCE.

N�o sei porque mas eu ainda acho a gambiarra do call stack menos bizonha (provavelmente porque eu ainda acho que o AspectJ era uma boa id�ia)

Re:Monkeypatching is Destroying Ruby

tnaires — GMT

[quote=Maur�cio Linhares]N�o sei porque mas eu ainda acho a gambiarra do call stack menos bizonha (provavelmente porque eu ainda acho que o AspectJ era uma boa id�ia) [/quote]
Desculpe a ignor�ncia, mas por que AspectJ n�o seria considerada uma boa id�ia nesses dias?
Pergunto porque este m�s comecei a estudar POA com AspectJ...

Re:Monkeypatching is Destroying Ruby

Mauricio Linhares — GMT

[quote=tnaires]Desculpe a ignor�ncia, mas por que AspectJ n�o seria considerada uma boa id�ia nesses dias?
Pergunto porque este m�s comecei a estudar POA com AspectJ...[/quote]

Porque a necessidade de uma ferramenta de AOP pra fazer alguma coisa � um sinal de que a linguagem n�o oferece facilidades pra altera��o das defini��es de objetos e classes em tempo de execu��o boas ou simples o suficiente.

Re:Monkeypatching is Destroying Ruby

Proteu Alcebidiano — GMT

Hum...acho que se voce transformar o seu bloco numa proc atraves de lambda e em seguida dar um call na proc, resolve o problema:

A sugest�o para a bazooka procedeu sem problemas

[code]
def fire(&block)
lambda(&block).call(instance_eval(&block))
end
[/code]

e para as risadas malevolentes:

[code]
def huhuhu(&block)
lambda(&block).call(instance_eval(&block))
end
[/code]

S� tem uma coisa que n�o entendi, para a segunda sugest�o que passei, ele retorna
[code]
nil
"risada maquiavelica"
122
test.rb:7:in `hehe': undefined local variable or method `bwawawawawa' for # (NameError)
from test.rb:13:in `call'
from test.rb:13:in `huhuhu'
from test.rb:7:in `hehe'
from test.rb:21
[/code]

porque diabos a saida est� assim, acusando erro de escopo mesmo imprimindo o valor do referido m�todo? e porque a ordem de impress�o dos atributos ficou invertida?

pior nem � isso. Quando eu inverto os valores em

[code]
def hehe
B.new.huhuhu{p bwawawawawa; p @abc}
end
[/code]

ele imprime:

[code]
"risada maquiavelica"
nil
test.rb:7:in `hehe': undefined local variable or method `bwawawawawa' for # (NameError)
from test.rb:13:in `call'
from test.rb:13:in `huhuhu'
from test.rb:7:in `hehe'
from test.rb:21
>Exit code: 1
[/code]

Algu�m consegue explicar isso?

T+

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Glaucio, voc� est� executando o mesmo bloco v�rias vezes, n�o? A id�ia � executar uma vez s� e ter acesso aos m�todos necess�rios nesta execu��o. Executar o mesmo bloco diversas vezes � invi�vel na maioria dos cen�rios para uma linguagem n�o funcional (que tem estado m�tavel).

Btw, algu�m implementa uma gambi com currying?

Re:Monkeypatching is Destroying Ruby

nbluis — GMT

[quote=pcalcado]Ser� que JRuby n�o consegue resolver o seundo problema com classloaders diferentes? N�o tenho id�ia, n�o sei como o JRuby funciona... LOOOOOOOOOOOOOOUUUUUDS!!![/quote]
[quote=louds]Acho que usando 2 instancias, uma para a aplica��o e outra para a DSL, com call by value, iow serializa todos argumentos, provavelmente funciona.[/quote]

Com Rubinius + MultiVM (que n�o sei a quantas isso anda) deve funcionar parecido n�o ?

Re:Monkeypatching is Destroying Ruby

Fabio Kung — GMT

[quote=pcalcado]S�o dois problemas. Um � a falta de op��es de binding, fazendo com que eu tenha quea alterar classes (adicionar m�todos em inteiros) quando o que eu queria era simplesmente que um m�todo estivesse disponivel em um contexto qualquer. Outro � o fato de que se eu alterar uma classe (como consequ�ncia do primeiro ou n�o) eu altero ela em todo o sistemas.

Ser� que JRuby n�o consegue resolver o seundo problema com classloaders diferentes? N�o tenho id�ia, n�o sei como o JRuby funciona... LOOOOOOOOOOOOOOUUUUUDS!!![/quote]
Se n�o me engano, cada classe Ruby vira um objeto de verdade na JVM. Inst�ncia de RubyClass, ou algo do tipo.

N�o precisa de v�rios ClassLoaders pq n�o � est�tico. Bastaria fazer com que os escopos pudessem estar associados a vers�es modificadas do RubyClass original. Isso n�o deve ser muito dif�cil de fazer, mas eu acho que a chance de fazerem deve ser perto de nula, j� que isso faria com que o JRuby n�o fosse compat�vel com o MRI.

De qq forma, acho que vale um papo com o Nutter e cia no #jruby @ freenode, ou na lista do jruby-dev.

Re:Monkeypatching is Destroying Ruby

Proteu Alcebidiano — GMT

[quote=pcalcado]Glaucio, voc� est� executando o mesmo bloco v�rias vezes, n�o? A id�ia � executar uma vez s� e ter acesso aos m�todos necess�rios nesta execu��o. Executar o mesmo bloco diversas vezes � invi�vel na maioria dos cen�rios para uma linguagem n�o funcional (que tem estado m�tavel).

Btw, algu�m implementa uma gambi com currying?[/quote]

Opa,

voc� tem raz�o, o que propus parecia trapa�a para solucionar o problema, e o que � pior, nem currying para isso funciona direito porque lambda tenta processar o bloco com tudo o que tiver dentro dele o_O

O ponto �: lambda.call enxerga o escopo de A e tenta evocar o de B (dando a tal unresolved variable), instance_eval enxerga o escopo de B e n�o enxerga o de A.

De todo modo, o problema da bazooka pode se resumir a:

[code]
def fire(&block)
lambda(&block).call
end
[/code]

No caso do exemplo das risadas, n�o sei como proceder...nao sei como, mas se lambda pudesse aceitar algo tipo:

[code]
def fire(&block)
lambda(&block, self).call #arrumem uma nota��o melhor :D
end
[/code]

Seria interessante, pois poderiamos fazer o bloco enxergar o escopo externo ao bloco

T+

Re:Monkeypatching is Destroying Ruby

nbluis — GMT

[quote=Proteu Alcebidiano]
[code]
def fire(&block)
lambda(&block, self).call #arrumem uma nota��o melhor :D
end
[/code]

Seria interessante, pois poderiamos fazer o bloco enxergar o escopo externo ao bloco

T+[/quote]

Nesse caso, eu ainda gosto da id�ia do binding hier�rquico. :D

Re:Monkeypatching is Destroying Ruby

louds — GMT

Fiquei pesando no seguinte, da mesma forma que se usa o Ycomb para implementar recurs�o em um lambda, ser� que n�o existe como derivar o fix point dos bindings e, ao ir adiante, ir chamando tudo via algo semelhante ao Ycomb?

Re:Monkeypatching is Destroying Ruby

Proteu Alcebidiano — GMT

[quote=louds]Fiquei pesando no seguinte, da mesma forma que se usa o Ycomb para implementar recurs�o em um lambda, ser� que n�o existe como derivar o fix point dos bindings e, ao ir adiante, ir chamando tudo via algo semelhante ao Ycomb?
[/quote]

Rapaz, usando a id�ia de combinators em bindings seria interessante porque voce poderia mudar a regra de binding sem precisar modificar o runtime da linguagem, e considerando que bindings realizam a��es (fun�oes) de refer�ncia, poderia-se criar uma high-order function para bindings...algo tipo, numa implementa�ao de Y-comb (pegar [url=http://erlang.org/pipermail/erlang-questions/2003-January/006633.html]uma implementa��o[/url] em erlang, pra facilitar a leitura)

[code]
y(X) ->
F = fun (P) -> X(fun (Arg) -> (P(P))(Arg) end) end,
F(F).
[/code]

voce ter uma funcao de counting ou binding regstry, que seria acionada pelo analisador a cada vez que um comando dentro de um bloco n�o estivesse definido no escopo mais "raso" do c�digo:

[code]
% chamem o rapazinho aqui para registrar bindings
count_binding() ->
F=fun (SUM) -> fun (N) ->
%registrar uma contagem ou qualquer tralha que d� uma chance ao c�digo do bloco, exemplo
%SUM(N) -> N + SUM(N-1)
%SUM(1) -> N.
end,
end
y(F).
[/code]

ou ent�o, se n�o quiser fazer algo hier�rquico, colocar numa hash ou lista ao inv�s de um contador.

Algo assim procede ou tou viajando? =D

T+

Monkeypatching is Destroying Ruby

Luca — GMT

Ol�

[quote=pcalcado]Eu acho que monkey patching � algo abusado em Ruby. [/quote]

http://gbracha.blogspot.com/2008/03/monkey-patching.html

[quote=Gilad Bracha]Regardless, given my flattering portrayals of primate practices, you may deduce that my main comment on monkey patching is ?just say no?. The problems it induces far outweigh its benefits. If you feel tempted, think hard about design alternatives. One can do better.[/quote]

Tamb�m acho arriscado permitir que isto aconte�a.

[]s
Luca

Re:Monkeypatching is Destroying Ruby

pcalcado — GMT

Esse artigo me deixou bem interessado em COP. Pena que a leitura vai ter que esperar um bom tempo na fila...