Joel VanderWerf
11/14/2004 9:26:00 PM
Florian Gross wrote:
> Joel VanderWerf wrote:
>
>> Disadvantages:
>>
>> - A container's services live in the same namespace as the methods
>> inherited from Kernel and Object, so a service called "dup", for
>> example, will prevent calling Object#dup on the container (except in
>> the implementation of the dup service, which can use super to invoke
>> Object#dup). The MinDI framework itself adds a few methods that
>> could conflict with services (#singleton, #generic, etc.).
>
>
> They can still be called in a wordy way:
> Object.instance_method(:dup).bind(container).call
>
> Maybe this could be wrapped into a small helper method?
Sure, thanks for the suggestion.
I don't know if it the namespace problem is really so bad though. It
happens in the following case:
class MyContainer
extend MinDI::Container
singleton :dup do # or threaded or some other service model
#...
end
end
cont = MyContainer.new
cont.dup
But that looks like a design problem to me. Maybe I will feel
differently for methods like #hash, though.
The only other problem I can think of is when using the shortcut (via
method missing) to define services:
class MyContainer
extend MinDI::Container
foo { Foo.new } # ok
dup { Dup.new } # not ok - definition not applied
hash { Hash.new } # not ok
end
This won't work, of course, but it shouldn't be expected to.
My current feeling is that it's just better to be aware of what already
exists in the namespace of MyContainer, just as one does when defining
normal classes.