Bug in Docile gem?

[ms-ati]

Hi @eropple! My name is Marc, I'm the author of the Docile gem. I noticed in your codebase mentions that it caused you problems with regard to instance variables.

Might I trouble you for a bug report or other explanation of the issue, so that a fix might be possible?

Thank you!
-Marc

[eropple]

Hi Marc--it's been a few years since I ran into it, sorry - I recall that @seanedwards ran into similar in the past with Cfer, maybe he remembers?

[seanedwards]

Hey @ms-ati - I worked around it in my own project by reverting to Docile 1.1. It's been a while since I looked into it, but here's the original bug report. seanedwards/cfer#50

If I recall correctly, the issue is reproducible with something like

a = true

my_dsl do
  some_value a
end

[ms-ati]

@seanedwards Thanks -- unfortunately this, and the linked issue, don't provide enough information to know if this bug continues to exist, nor the cause. Would it be possible to help me understand? If so I can find a docile version that fails (has the bug in question), it would become much more likely that we can find a fix?

[ms-ati]

@seanedwards @eropple Hi, just pinging again to see if the observed issues still exist in current Docile? I'd really appreciate the chance to reproduce the issue if it still exists, so that it can be fixed.

Thanks,
-Marc

[eropple]

Sorry, I'm out of the Ruby ecosystem almost entirely and don't have an environment with which to test anything.

…

On Tue, Oct 22, 2019 at 1:38 PM Marc Siegel ***@***.***> wrote: @seanedwards <https://github.com/seanedwards> @eropple <https://github.com/eropple> Hi, just pinging again to see if the observed issues still exist in current Docile? I'd really appreciate the chance to reproduce the issue if it still exists, so that it can be fixed. Thanks, -Marc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AAA2VTUJMLHKFJWZERYBC3LQP43ADA5CNFSM4IYNTQUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6SP7I#issuecomment-545073149>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2VTR6J6R7OHR7YK5ROW3QP43ADANCNFSM4IYNTQUA> .

-- Ed Ropple Twitter: https://twitter.com/edropple Github: https://github.com/eropple

[seanedwards]

@ms-ati I spent a little time digging into this, and it appears that the root of the issue is that my project implements a DSL using method_missing and respond_to?. tl;dr background, the DSL takes ruby statements that look like some_key "some_value" and transforms them into JSON objects that look like {"SomeKey": "some_value"} to assist in writing AWS CloudFormation templates.

Because my DSL allows any method to be called as part of teh DSL, the DSL object will always say it responds to a method name, and so when Docile asks if __docile_undo_fallback__ is supported, my object says "Sure, send it over!". https://github.com/ms-ati/docile/blob/def1671ce4993cac32cbc329be3d4c7685b7a1d4/lib/docile/fallback_context_proxy.rb#L86-L88

If I add :__docile_undo_fallback__ to my own list of "non-proxied methods" (i.e. methods which are explicitly not supported by the DSL) then my project appears to play nice with the latest version of Docile.

If you have any documentation or advice on how to best handle this case, where a DSL is implemented using method_missing that would be helpful. But it appears to not actually be a Docile bug after all, just a strange edge case between the two projects.

[ms-ati]

Thank you so much @seanedwards. This is not a use case I had anticipated, but it does make sense. Let me see if I can engineer a guard for this on the Docile side