I am trying to get the hang of IoC and DI and am using Castle Windsor. I have an object I have created that can be multiply instantiated but over different generic types. For example
MyType<Generic, Generic2>
on Installation of MyType's assembly
container.Register(Component.For(typeof (IMyType<>)).ImplementedBy(typeof (MyType<>)));
Then in my main modules initialization I install MyTypes module with MyTypeInstaller which is a IWindsorInstaller.
Then I am manually resolving the various types of MyType that I want (this will actually be spread around different installers). But something like
container.Resolve<IMyType<type1, type2>();
That creates an actual instance of MyType registered for the generic types passed in.
This works fine, I get the instances of MyType<,> I need created.
Now, finally I have another module I have created that I will install last. I want to say,
container.ResolveAll<IMyType<,>>()
then create this instances of this new object for each object that exists.
However I cant seem to resolve all of the IMyTypes<,> without knowing the concrete types that each one were instantiated as.
At any rate, it is possible I am just doing this wrong and want feedback in general as well.
First, if MyType<T1,T2> can only be instantiated once for each combination of T1,T2 then you should be registering it is a Singleton.
Second, You cannot call strongly type container methods (like ResolveAll<T>) with an open generic - it MUST be a closed type.
Third, MyType is an open generic type and the number of closed generic classes is infinite (generic type constraints are not considered by the container). So, as far as the container is concerned you can call Resolve<ANYTHING, ANYTHINGELSE> and it will attempt to provide a MyType<ANYTHING,ANYTHINGELSE> for you. If ANYTHING and ANYTHINGELSE don't satisfy the type constraints then you will simply get a run time error.
Even if you could call ResolveAll<IMyType<,>>() what would you expect it to return given that you have registered an open generic implementation?
Related
I built a custom block that, among other things, tells the resource entering portIn of the block to move to the resource's seizing unit. I use a moveTo block with the destination node as: (Node)((Cart)agent).getServicedEntity().getNetworkNode(); but I need to know the agent type and cast it into the method. I would like to make this a generic block that can be used in other models and with any Resource Unit.
I've tried using generic parameters in the custom block
then selecting the agent type:
and then trying: (Node)T.getServicedEntity().getNetworkNode(); but this results in compiling error: The method getServicedEntity() is undefined for the type T. Is there a way to do what I'm looking to do? I'm fine if the user has to select the agent type using the generic parameter pulldown, but I'd like to avoid having to change the code every time to add in all of the resource types available in the model using the instanceof command and then duplicating the code. Seems inefficient.
Well, your "T" extends Agent, and Agent does not know about getServicedEntity.
What your T extends needs to know it is a resource unit. Easiest solution I can see:
Create a parent class MyResourceUnit (but do not instantiate it)
Make sure it is "used in flowcharts as Resource Unit"
Make all agent types that should ever use your custom block to extend MyResourceUnit
Now in your custom block, you should make T extends MyResourceUnit
I have a use case where I need to create a class based on user input.
For example, the user input could be : "(Int,fieldname1) : (String,fieldname2) : .. etc"
Then a class has to be created as follows at runtime
Class Some
{
Int fieldname1
String fieldname2
..so..on..
}
Is this something that Scala supports? Any help is really appreciated.
Your scenario doesn't seem to make sense. It's not so much an issue of runtime instantiation (the JVM can certainly do this with reflection). Really, what you're asking is to dynamically generate a class, which is only useful if your code makes use of it later on. But how can your code make use of it later on if you don't know what it looks like? For example, how would your later code know which fields it could reference?
No, not really.
The idea of a class is to define a type that can be checked at compile time. You see, creating it at runtime would somewhat contradict that.
You might want to store the user input in a different way, e.g. a map.
What are you trying to achieve by creating a class at runtime?
I think this makes sense, as long as you are using your "data model" in a generic manner.
Will this approach work here? Depends.
If your data coming from a file that is read at runtime but available at compile time, then you're in luck and type-safety will be maintained. In fact, you will have two options.
Split your project into two:
In the first run, read the file and write the new source
programmatically (as Strings, or better, with Treehugger).
In the second run, compile your generated class with the rest of your project and use it normally.
If #1 is too "manual", then use Macro Annotations. The idea here is that the main sub-project's compile time follows the macro sub-project's runtime. Therefore, if we provide the main sub-project with an "empty" class, members can be added to it dynamically at compile time using data that the macro sees at runtime. - To get started, Modify the macro to read from a file in this example
Else, if you're data are truly only knowable at runtime, then #Rob Starling's suggestion may work for you as it did me. I'll share my attempt if you want to be a guinea pig. For debugging, I've got an App.scala in there that shows how to pass strings to a runtime class generator and access it at runtime with Java reflection, even define a Scala type alias with it. So the question is, will your new dynamic class serve as a type-parameter in Slick, or fail to, as it sometimes does with other libraries?
Let's say I have a number of GWT modules which are used as libraries, and one module with an entry point which inherits all of the library modules.
Each of the submodules needs to access a single instance of SomeClass.
If I call GWT.create(SomeClass.class) in modules A & B, do I get the same instance? If so, is this guaranteed?
No. GWT.create(SomeClass.class) compiles to new SomeClass(), unless there is a rebind rule of some kind - a replace-with or a generate-with rule will cause this to instead invoke the default constructor of whatever type is selected by those rules.
This means that GWT.create is not a suitable way to provide access to a singleton instance. Instead, consider some DI tool like Gin, or manual DI by always passing around the same instance. It is also possible to use the static keyword to keep a single instance where all code compiled into the same app can reference it.
I am starting to learn, MEF and one important thing in it is that I can mark some item (class, propety,method) with Export attribute so that, who ever wants use it will create Import attribute on an instance varaible and use it. How does this mapping happen and when does it happen? Is the import happen lazily on demand or all the composition happen at the start up? Sorry for the ignorant question, I am trying to understand the flow.
It happens in a phase called "Composition". First you create a container and load all your possible sources of parts into it, and then you Compose it. When you do the composition, it resolves all the dependencies and throws an exception if it can't resolve them all properly.
In general, your parts get instantiated during composition (and if you set a break point in the constructor of your part classes, you will see the break point hit during your call to Compose()). However, you can override this in a straightforward way if you use Lazy<T> as the type of your import (assuming you exported your part as type T).
To see how the composition works, take a look at the Compose() method here.
How can I pass a null constuctor argument using Castle Windsor? I thought the following would work
<parameters>
<repository>null</repository>
<message>null</message>
</parameters>`
If you want them to be null, it means that they are non-essential dependencies. By having them as ctor arguments you suggest otherwise. You should redesign your class to have another constructor that takes only essential dependencies, if you wish that they not change throughout the lifetime of an object (be readonly), or expose them as properties.
With Windsor you can't make it to pass nulls, for reasons mentioned in the other answer.
Wouldn't it better to simply have an additional public constructor that doesn't take these parameters, then you wouldn't need to register the parameters in the config?
This was discussed a while back on the mail list, and at the time I looked into the code. Null values are deliberately filtered out (mainly because the complicate type resolution).
I couldn't find a simple way to make a special case to add them.