While testing Kiba 2.0.0.rc1 on a client codebase, I met a situation where a client-declared module named DSLExtensions was shadowed by the new Kiba::DSLExtensions containing the new Config.
Before this PR, the Parser (calling instance_eval) was declared like this:
module Kiba
module Parser
end
end
As I discovered, just changing the declaration to this instead:
module Kiba::Parser
end
seems to hide the Kiba classes further enough to avoid the conflict mentioned above.
I expect that a better blank-slate approach will likely be needed at some point in the future, but this seem to be good enough for the upcoming v2, and will at least make sure that clients using the DSLExtensions module to group DSL extensions (very commonly used by my clients) won't see a conflict due to the introduction of Kiba::DSLExtensions::Config.
While testing Kiba 2.0.0.rc1 on a client codebase, I met a situation where a client-declared module named
DSLExtensionswas shadowed by the newKiba::DSLExtensionscontaining the newConfig.Before this PR, the
Parser(callinginstance_eval) was declared like this:As I discovered, just changing the declaration to this instead:
seems to hide the Kiba classes further enough to avoid the conflict mentioned above.
I expect that a better blank-slate approach will likely be needed at some point in the future, but this seem to be good enough for the upcoming v2, and will at least make sure that clients using the
DSLExtensionsmodule to group DSL extensions (very commonly used by my clients) won't see a conflict due to the introduction ofKiba::DSLExtensions::Config.