Is there some way to RegisterType in autofac with an optional parameter? I.e. in the past we had something like
builder.Register(c => new Bla(c.ResolveOptional<Blub>())
Which obviously fails with RegisterType.
So, any way to do that? Probably I'm just really blind -.-
Turns out I was thinking too complicated. The answer is simply: default parameters in the constructor.
class Bla
public Bla(Blub blub = null)
Autofac is bright enough to fill them if the type is registered but just leaves them otherwise.
Constructor dependencies should not be optional. Instead register an empty implementation (a.k.a. a Null Object) you don't need any implementation. This simplifies the consuming component, since it doesn't have to deal with null values and can always expect there to be a valid implementation.
Related
Coming from the Java world, I don't see how the restrictions on the auxiliary constructors in Scala are helpful ..
In Java, I know we can have multiple constructors as long as their signatures are different.
In Scala, the first call in an auxiliary constructor needs to be another auxiliary constructor or the class's primary constructor. Why? Doesn't this make Scala more restrictive?
Scala essentially guarantees that the primary constructor will always be called, so it gives a single point of entry to the class; FOREVER. You ALWAYS know that the primary constructor will be called, no matter which auxiliary constructor you use to create the object.
Did you even experience having all your nice initialization in your (say) argument-less constructor in Java, and then you (in the future) or someone else coming along creating another constructor and then your objects are not correctly initialized and start miss-behaving? Probably not the best design in the world, but I faced this, and it wasn't fun.
Well, in Scala you never have to worry about this, if you have something in your primary constructor it will always be called or else the code will not compile. In my vocabulary it's not a restriction, it's called "Peace of Mind".
Scala doesn't support multiple constructors like Java. While this may seem like an inconvenience, in return you get less boilerplate. And with factory methods in the companion object you end up getting a richer syntax for construction.
Scala needs to have a primary constructor because you can include declarations in it and eliminate the tedious boilerplate of initializing a field in the constructor.
class Rectangle(val width: Int, val height: Int) {
def this(size: Int) = this(size, size)
}
Note that the 'val' keywords in the default constructor declare two public fields. The idiomatic Java equivalent would have a lot more boilerplate (two getters, plus initialization in the constructor).
Actually in practice most developers prefer factory methods in the companion object (e.g. Rectangle(4) instead of new Rectangle(4, 4)), which is more flexible overall.
The documentation says this is allowed:
ClassMethod GetContacts() As %ListOfObjects(ELEMENTTYPE="ContactDB.Contact")
[WebMethod]
I want to do this:
Property Permissions As %ListOfObjects(ELEMENTTYPE="MyPackage.MyClass");
I get an error:
ERROR #5480: Property parameter not declared:
MyPackage.Myclass:ELEMENTTYPE
So, do I really have to create a new class and set the ELEMENTTYPE parameter in it for each list I need?
Correct syntax for %ListOfObjects in properties is this one
Property Permissions As list of MyPackage.MyClass;
Yes, a property does sometimes work differently than a method when it comes to types. That is an issue here, in that you can set a class parameter of the return value of a method declaration in a straightforward way, but that doesn't always work for class parameters on the class of a property.
I don't think the way it does work is documented completely, but here are some of my observations:
You can put in class parameters on a property if the type of the property is a data-type (which are often treated differently than objects).
If you look at the %XML.Adaptor class it has the keyword assignment statement
PropertyClass = %XML.PropertyParameters
This appears to add its parameters to all the properties of the class that declares it as its PropertyClass. This appears to be an example of Intersystems wanting to implement something (an XML adaptor) and realizing the implementation of objects didn't provide it cleanly, so they hacked something new into the class compiler. I can't really find much documentation so it isn't clear if its considered a usable API or an implementation detail subject to breakage.
You might be able to hack something this way - I've never tried anything similar.
A possibly simpler work around might be to initialize the Permissions property in %OnNew and %OnOpen. You will probably want a zero element array at that point anyway, rather than a null.
If you look at the implementation of %ListOfObjects you can see that the class parameter which you are trying to set simply provides a default value for the ElementType property. So after you create an instance of %ListOfObjects you could just set it's ElementType property to the proper element type.
This is a bit annoying, because you have to remember to do it every time by hand, and you might forget. Or a maintainer down the road might not now to do it.
You might hope to maybe make it a little less annoying by creating a generator method that initializes all your properties that need it. This would be easy if Intersystems had some decent system of annotating properties with arbitrary values (so you could know what ElementType to use for each property). But they don't, so you would have to do something like roll your own annotations using an XData block or a class method. This probably isn't worth it unless you have more use cases for annotations than just this one, so I would just do it by hand until that happens, if it ever does.
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.
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.
can anyone explains to me what "context binding" at runtime in AspectJ is, and in what ways is it different from reflection? In particular, if I need to get an annotation from a class woven by a given aspect, context binding:
after(MyAnnotation annotation) : execution(* Foo.*(..)) && #this(annotation)
or reflection:
MyAnnotation myAnnotation = thisJoinPoint.getThis().getClass().getAnnotation(MyAnnotation.class);
can be used, but what is the best solution (that is, the quickest one)?
You are better off using the former. Creating thisJoinPoint objects are expensive since all fields must be filled in when accessed. Therefore, AspectJ will only create one if required.
Accessing the annotation via advice is generally faster since the compiler has more of a chance to optimize. Furthermore, it is more strongly types (your second example has a type error).