Ayende @ Rahien

Justin Chase commented on Instantiating interfaces

Sat, 29 Aug 2009 17:07:23 GMT

We use this a little at work for instantiating certain COM objects. It's useful when you have a guid of a type but not a type library. You create the interface to match the signature of the type (or just the parts you care about) and then you can access that object strongly typed. I believe this is what the interop assemblies do when you add a reference to a COM assembly also.

Mark Seemann commented on Instantiating interfaces

Thu, 20 Aug 2009 03:46:46 GMT

Now look what you did: [stackoverflow.com/.../newing-up-interfaces](http://stackoverflow.com/questions/1303717/newing-up-interfaces) I just knew it was going to happen :/

Mats Helander commented on Instantiating interfaces

Tue, 18 Aug 2009 12:47:56 GMT

Jason, That's what I think (and do) too, but apparently we're using the "bastard child" (of IoC) approach ;-) /Mats

Jason Y commented on Instantiating interfaces

Tue, 18 Aug 2009 12:33:23 GMT

Is there any reason not to have the following in the same module?: interface IFoo { AMethod(); } class TypicalFoo { AMethod() {...} } Though you don't get a truly default Foo, you _can_ document it as the one to fall back on "by default" so that it can be used as the default. Is this a common pattern? I find myself doing it all the time.

Ayende Rahien commented on Instantiating interfaces

Sun, 16 Aug 2009 09:50:24 GMT

RichB, Yes, it should

RichB commented on Instantiating interfaces

Sun, 16 Aug 2009 08:18:08 GMT

Do you know if this still works if the assembly is assembly:ComVisible(false)? I suspect that as you say it's a compiler feature, you don't need the types to be registered anywhere for it to work.

Stephen commented on Instantiating interfaces

Sat, 15 Aug 2009 17:12:03 GMT

I read this the other day, I don't think theres anything really interesting you can do with it, its purely there to make certain com interop neater (as the example was office I think).

Bruce Boughton commented on Instantiating interfaces

Sat, 15 Aug 2009 16:34:42 GMT

Of course I meant: ServiceLocator.Current.GetInstance();

Bruce Boughton commented on Instantiating interfaces

Sat, 15 Aug 2009 16:33:33 GMT

I wonder if this it is possible to define a co-class FooImpl that loads an IFoo using dependency injection and then passes all IFoo calls through to it: public class FooImpl : IFoo { private readonly IFoo foo; public FooImpl() { this.foo = ServiceLocator.Current.GetInstance

Ayende Rahien commented on Instantiating interfaces

Sat, 15 Aug 2009 12:00:00 GMT

Tuna, No, I checked

Thomas Eyde commented on Instantiating interfaces

Sat, 15 Aug 2009 09:04:00 GMT

My guess is it's in there because of VB.NET. Or to make COM libraries easier to use. Classic VB hid all COM nastiness from us. When we declared a class CPerson, we also had an interface CPerson. Or so we thought. Our C++ friends using our VB made libraries could tell otherwise.

Tuna Toksoz commented on Instantiating interfaces

Sat, 15 Aug 2009 08:19:59 GMT

Can we make it call a service locator? :) var x=new IFoo(); turns out to var x=container.Resolve

liviu commented on Instantiating interfaces

Sat, 15 Aug 2009 08:08:17 GMT

What if Foo would be just a wrapper class araound an IFoo that is resolved using an DI container. The advantage would be that i don't have to say: XXXFactory.Create

Eugene Burmako commented on Instantiating interfaces

Sat, 15 Aug 2009 07:45:08 GMT

I remember Eric Lippert posted similar stuff: "how is it that Foo foo = new Foo(); can cause a runtime conversion failure? And how is it that Bar bar = (Bar)(new Baz()); can succeed even if there is no user-defined conversion or built-in implicit conversion between Baz and Bar?" So the second question is answered by Ayende, but the first one is still open. Don't immediately go to the link I provide below if you don't know the answer. Think a bit - it's almost on the surface in the _context_ of this discussion =) The promised link to Eric Lippert's post: [blogs.msdn.com/.../...ersions-in-c-part-three.aspx](http://blogs.msdn.com/ericlippert/archive/2007/04/20/chained-user-defined-explicit-conversions-in-c-part-three.aspx)

Mark Seemann commented on Instantiating interfaces

Sat, 15 Aug 2009 07:27:55 GMT

It's interesting that this can be done, but as far as I can see, this is conceptually similar to people doing DI and overloading their constructors with default dependencies. You recently wrote about that here: [ayende.com/.../reviewing-nerddinner.aspx](http://ayende.com/Blog/archive/2009/07/30/reviewing-nerddinner.aspx) calling it a 'bastard child', and I can only agree. In other words: Nothing to see here, please move along :)

Ayende Rahien commented on Instantiating interfaces

Sat, 15 Aug 2009 07:07:06 GMT

Nope, because it is a one to one association and it happen at compilation time. You _can_ create the abstraction line, but you can't do much with it except replace the destination class on compilation

junior programmer commented on Instantiating interfaces

Sat, 15 Aug 2009 06:56:41 GMT

does this mean we can use it for simple IoC/DI?

Bertrand Le Roy commented on Instantiating interfaces

Sat, 15 Aug 2009 05:52:31 GMT

Nice. Too bad you need the COM attribute goop. Interesting tip nevertheless.

Ayende Rahien commented on Instantiating interfaces

Sat, 15 Aug 2009 01:28:46 GMT

Bertrand, The generated IL is: var foo = new FooImpl(1); In other words, this is purely compiler magic and does nothing at all with COM

Bertrand Le Roy commented on Instantiating interfaces

Sat, 15 Aug 2009 00:39:56 GMT

Does it mean that you're going through COM interop just to do the instantiation? What makes that better than the alternatives?