I have started to use Autofac following this tutorials:
http://flexamusements.blogspot.com/2010/09/dependency-injection-part-3-making-our.html
Simple class with no parameter in the constructor
builder.RegisterType<ConsoleOutputService>().As<IOutputService>();
As explained in the tutorial, the code above can be read as: setup ConsoleOutputService as the implementation of IOutputService
Simple class with one parameter in the constructor
builder.Register(c => new MultipleOutputService(outputFilePath)).As<IOutputService>();
I don't understand why are we using a lambda expression to register this class (and what does this expression exactly does) and why we can't type this code
builder.RegisterType<MultipleOutputService(outputFilePath)>().As<IOutputService>();
Thanks in advance for your help
Btw there is a better solution to this Autofac introduced the .WithParameter() extension to their registration builder.
.RegisterType<MultipleOutputService>().As<IOutputService>().WithParameter("parameterName", "parameterValue");
This should cater for the event that you need to pass something other than an interface type to one of your constructors
You can't write that code because it doesn't make sense in C#.
RegisterType is a generic method; generic methods must take types as generic parameters.
You're trying to register a type with a custom way to create it (inyour case, a constructor parameter); the only way that C# supports to specify such a thing is a lambda expression (or other delegate).
The lambda variant enables us to do some logic when constructing the instance.
Related
Disclaimer: I'm still learning Swift so forgive me if I haven't understood certain concepts/capabilities/limitations of Swift.
With the Swinject framework, if you wanted to bind a protocol to a class - it seems you have to return the class instance in a closure such as:
container.register(Animal.self) { _ in Cat() }
Is is possible to be able to instead pass in two types to the register() method and have the framework instantiate the class for you? It would need to recursively see if that class had any initializer dependencies of course (Inversion of Control).
This is possible in the PHP world as you have the concept of reflection, which allows you to get the class types of the dependencies, allowing you instantiate them on the fly. I wonder if Swift has this capability?
It would be much nicer to write this:
container.register(Animal.self, Cat.self)
This would also allow you to resolve any class from the container and have it's dependencies resolved also (without manually registering the class):
container.resolve(NotRegisteredClass.self)
Note: This only makes sense for classes that do not take scalar types as a dependency (as they need to be explicitly given of course).
The second case - resolving a type without the explicit registration - is currently not possible because of Swift's very limited support for the reflection.
However, there is a SwinjectAutoregistration extension which will enable you to write something very close to your first example:
container.autoregister(Animal.self, initializer: Cat.init)
I have a method where an EStructuralFeature comes in as a parameter. I can get the type of the feature via the method getEType() and get the "real" Java class via the EType's getInstanceClass() method. So far so good. But what if this type is generic, and I want to know its special type? Unfortunately this information is gone due to Java's Type Erasure, but is there a way to achieve this by using EMF's functionality?
EStructuralFeature is an interface extends to ETypedElement
more details here:
[http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EStructuralFeature.html]
I have a method that takes type parameters with an implicit view bounds on them. Can I use the #implicitNotFound annotation to give nicer compiler errors when the method is called with invalid data types?
The documentation for the method is useless and even the source code doesn't help, and all the examples of use online are at the trait or class level.
No, you cannot directly do that. As you’ve noticed, #implicitNotFound annotates traits or classes. You could, however, make a special implicit type just for that method and annotate it if you really wanted to have a custom message.
interface test{
foo(boo:string);
}
class coo implements test{
foo(){
}
}
In playGround
this doesn't generate and error although the function signature is not as the interface
says, the expected behavior of interface is to force the signature..
why is this behavior?
Thanks
This is interesting. The TypeScript team are quite clever chaps and they decided to do this deliberately.
The idea is that if your function can operate correctly without being passed an argument, it can safely ignore the argument and satisfy the interface. This means you can substitute your implementation without having to update all of the calling code.
The interface ensures that the argument is passed in all cases where you are consuming the interface - so you get type checking on the callers and it actually doesn't matter that your concrete class doesn't need any parameters.
Interface Function Parameter Not Enforced
I am not satisfied how Interface doesn't enforce the method signature too. I believe the explanations by Fenton are wrong. The real reason is that Typescript is using "duck typing". No erros with less parameters, but you do get errors if you use more parameters.The long answer can be found here Why duck typing is allowed for classes in TypeScript
In the end, Interface can't fit the role of an abstract class that is extended by an other class. I wouldn't recommend to use Interface with classes but instead better use the word "implements" on an actual class, it does the same without the extra Interface class.
Typescript uses structural typing. The implemented function can have fewer parameters than the function declaration in the interface but not more.
Is it possible to create an AOP like interceptor using Scalas new Dynamic Type feature? For example: Would it be possible to create a generic stopwatch interceptor that could be mixed in with arbitrary types to profile my code? Or would I still have to use AspectJ?
I'm pretty sure Dynamic is only used when the object you're selecting on doesn't already have what you're selecting:
From the nightly scaladoc:
Instances x of this trait allow calls x.meth(args) for arbitrary method names meth and argument lists args. If a call is not natively supported by x, it is rewritten to x.invokeDynamic("meth", args)
Note that since the documentation was written, the method has been renamed applyDynamic.
No.
In order for a dynamic object to be supplied as a parameter, it'll need to have the expected type - which means inheriting from the class you want to proxy, or from the appropriate superclass / interface.
As soon as you do this, it'll have the relevant methods statically provided, so applyDynamic would never be considered.
I think your odds are bad. Scala will call applyDynamic only if there is no static match on the method call:
class Slow {
def doStuff = //slow stuff
}
var slow = new Slow with DynamicTimer
slow.doStuff
In the example above, scalac won't call applyDynamic because it statically resolved your call to doStuff. It will only fall through to applyDynamic if the method you are calling matches none of the names of methods on the type.