From: Joel VanderWerf <vjoel@...>
Date: 2004-11-15T06:25:44+09:00
Subject: Re: [ANN] MinDI: Minimalist Dependency Injection

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.