timriley on rename-boot-methods
Make methods private Rename Container.boot to .regis… Add “_bootable” suffix to init/… (compare)
timriley on support-component-dirs-with-mixed-namespaces
Fix error initialization (compare)
timriley on support-component-dirs-with-mixed-namespaces
Fix error initialization (compare)
timriley on support-component-dirs-with-mixed-namespaces
Fix error initialization (compare)
timriley on support-component-dirs-with-mixed-namespaces
Fix error initialization (compare)
timriley on support-component-dirs-with-mixed-namespaces
Extract Identifier; support mix… (compare)
@AMHOL @solnic As far as i inderstood, you've implemented namespace in dry-container
as... well, namespace :)
I mean, it seems like a syntax sugar for long keys like "namespace.name" added via namespaced(key)
method, innit?
I think, why not (re)implement it as a nested container(s), whose methods are available from the "parent" container via nested name.
This would allow importing "namespaces - containers" from one to another. Like in case:
foo = Dry::Container.new
foo.namespace(:bar) do
register(:baz) { :BAZ }
end
qux = Dry::Container.new do
import foo.namespace(:bar), as: :fbar # here resolve has to be reloaded to work with both variables and namespaces
# also namespace w/o block would just return the namespace
end
qux.resolve("fbar.baz") # => :BAZ
I think about this feature in connection to dry-data
. When I read dry-data, the first thing I asked myself is: how to take some types defined inside one module and inject them to another. Just like in Haskell:
import Data.Char (toLower, toUpper)
or in transproc (the same haskell-inspired mechanism)
import :camelize, from: Inflecto, as: :up