How could dependency injection be integrated into the language?

Question

I've been thinking a bit on how dependency injection could be better integrated directly into a C# like language. I've come up with a potential solution I'd like to hear your opinion on. I haven't used many dependency injection frameworks so there might be something I'm overlooking

Anyways, the idea is to be able to declare properties as "injectable" using a keyword. When an object is instantiated, and that property is not initialized through the constructor, or object initializer, it requests an instance of that property type from some global service.

Similarly you register handlers for different types to that service so that you can instantiate the injected property type.

The upside of using this kind of architecture IMO is that it's fairly flexible and easy to use. The downside is that there might be some overhead of doing the callout to the singleton each time you initiate a class that has injection.

Then again that's only an issue for classes that get's instantiated frequently in a high performance solution so it shouldn't be much of an issue. Perhaps you could use some kind of factory in those instances.

Thought, issues, questions, better ideas?

Code

public class SomeClass
{

  public SomeClass()
  {
     //implicit behavior if Animal is not set in constructor or initializer
    this.Animal =  GlobalInjector.Get(this,typeof(Mammal))

  }

  public injectable Mammal Animal  
  {
   get;
   set;
  }
}


 GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

Answer 1

There are things that belong in languages, and things that don't. Long ago C recognized that IO did not belong in the language because it is external to the computing model and can be implemented with function libraries.

Dependency Injection is like that. It's external to language and can be implemented with appropriate frameworks.

One of the problems with modern languages is that they try to do too much. Eventually those languages collapse under their own weight as programmers flee to simpler languages.

Answer 2

It isn't needed

One of the things I like best about the best DI frameworks I've used is that the top-level configuration code is the only part of your code that needs to know about DI. Auto-wiring is done at the container and configuration/"module-loading" level, and your application code can be completely oblivious to it.

This means no attributes, no magic strings, no convention. Each piece of code only knows that it accepts code in its constructor (/properties/methods), and that's all.

With a design like that you don't need to alter the language at all to support Dependency Injection.

It is potentially dangerous

The thing I fear most about a language-integrated dependency injection system is that it would raise a barrier against any other implementation, yet it would probably paint itself into a corner in some aspect.

Some ways it could paint itself into a corner:

• Only supporting XML-based configuration, or only code-based configuration
• Not being able to cleanly support the Factory design pattern (not just transient components: run-time generated components)
• Somehow changing my code so I was forced to use dependency injection, and couldn't simply instantiate my class for unit tests
• Not supporting custom lifecycles
• Not being extensible
• Not being replaceable in cases where I need greater customization
• Being broken in some way that we don't understand yet, because us .Net users haven't been using DI long enough to know the pitfalls

Answer 3

Have you seen the Managed Extensibility Framework that comes with .NET 4? Here's an article I wrote with some examples. Basically it's a form of dependency injection built into .NET, with the added features of run-time discoverability.

Property injections look like this:

class Program
{
    [Import]
    public IMessageSender MessageSender { get; set; }
}

Constructor injections look like this:

class Program
{
    [ImportingConstructor]
    public Program(IMessageSender messageSender) 
    {
    ...
    }
}

You can import fields, do optional import, import collections of services, including doing lazy importing with metadata so you can search for an appropriate service to instantiate. You can even re-import at runtime to look for new extensions.

Answer 4

1. You don't really describe the configuration mechanism, which IMHO is the tricky bit. How do you make all code running in one thread use DB-connection A, und all code in the other thread connection B? How do you block injection of a certain resource, because the user currently logged in is not allowed to access it?
2. Don't use a global injector. Don't use any global thing at all, or you might as well use global variables. No, using OOP-speak such as singleton or "static" instead of global doesn't change their global nature.
3. Consider a dynamically scoped container. While lexical scoping has rightfully won against dynamic scoping, I believe that dynamic scope would make a fine replacement for global scope. Differential inheritance would be a nice implementation (like in prototype-based inheritance).
4. I believe that a language-mandated DI-mechanism should be really simple, none of that enterprisey stuff that is the norm in C# and Java. A dynamic scoping mechanism with a simple configuration layer on top might do the trick. Enterprisey solutions could be layered on top by third parties.