I'm trying to build a better Flowtype definition for Koa library and am kinda stuck.
My idea was to use Generic types to be able to specify customized Context class to Koa, so we can actually typecheck additional fields (populated by middlewares) instead of treating them as any.
so, I have:
declare type Context {…}
declare class Application<T: Context<T>> extends events$EventEmitter {
context: T,
…
}
fine…
but Context has a back-reference to Application, which is a generic dependent on Context. How do I spell this in typelib?
This doesn't look right, as I actually want to use not original Context but the type which was actually used by user
declare type Context {
app: Application<Context>
}
Related
Given the following classes
abstract class SomeAbstractClass { abstract val name: String }
data class DataClass( override val name: String ) : SomeAbstractClass()
class NoDataClass( override val name: String ) : SomeAbstractClass()
For any instance of SomeAbstractClass, can I determine whether it is a data class without relying on type checking?
Some background: this seemed the best way of combining inheritance and data classes to me, as suggested in a different answer. Now, within the initializer block of SomeAbstractClass, I want to throw an exception in case the derived type is not a data class to ensure 'correct' (immutable) implementations of derived types.
Using reflection, the Kotlin class description (KClass) can be obtained using the ::class syntax on the instance you want to investigate (in your case, this::class in the initializer block of the abstract class). This gives you access to isData:
true if this class is a data class.
However, as Oliver points out, data classes can still contain var members, so you likely also want to check whether all member variables (and their member variables recursively) are defined as val to ensure immutability of all deriving classes.
I started learning ASP.NET MVC and I have got some doubt. How do I check if a class is a Model class in MVC. I have PHP Codeigniter background, where all models inherit CI_Model. It was easy to figure out whether a class is a model class or not by checking instanceof operator but in .NET MVC Model class do not extend any class.
So how do I figure out whether a class is a model class through C# Code? How does MVC framework figure out whether the class is model or not. I have renamed folder from "Models" to "Modelss" but still model binding works with ModelState.IsValid. Any help is greatly appreciated.
Most models in an MVC application are plain old CLR objects (POCOs), that often don't have a base class because it isn't needed. You can change that, if you need to.
In the following examples, lets assume you have a object called param coming in from somewhere.
In C#, you can check if an object is of a certain type in a few ways. You can cast the object to the type, and if you don’t get an exception, the cast was successful. This is not the preferred method any longer, but I wanted you to know if was an option.
try {
var myType = (MyModel)param; // cast happens here
// do something with myType
}
catch{
// cast failed
}
Another way is to use the as operator. This is a much better way to do this because no exception is thrown if the cast fails, you just get null in the variable.
var myType = param as MyModel;
if (myType != null) { // you have what you need.
...
}
Another technique is the is operator (another good way). This works similar to as, but returns a Boolean rather than the object, or null, and you can inline it in an if statement to do the cast, and assign to a variable all in one line of code.
if (param is MyModel myType){
// do something with myType
}
If you do add a base class to your models, you can use that type rather than the class name in the examples above. If you want, you can forego the base class and use a marker interface (an interface with no properties, or functions declared in it), and check for that type.
public interface IModel {}
public class MyModel : IModel {
...
}
if (param is IModel myType){
// do something with myType
}
BTW, changing the folder name in the project didn't make any difference because C# works based on namespaces, and not folder structure, for most application types. As long as the folder and class files are included in the project, and the namespace is referenced, all is good.
Hope you find this information useful!
For example, let's say I have an interface 'IFeed' and two concrete types ('Feed1' and 'Feed2') that implement this interface. Now let's say I have a 'FeedManager' type that takes multiple parameters that will get resolved dynamically, two of which are of type 'IFeed' and I'd like both concrete type to be injected via constructor injection, not via manual resolve (I only use resolve once at the composition root). I have a feeling that I should be using a factory but I wanted to see what the proper way of doing this might be. Many thanks in advance.
If you want ALL implementations of IFeed, you can use array syntax in your constructor and then nothing special is needed at type registration time.
container.RegisterType<IFeedManager, FeedManager>();
container.RegisterType<IFeed, FeedA>("FeedA"); // The name doesn't matter
container.RegisterType<IFeed, FeedB>("FeedB"); // The name doesn't matter
Then the manager constructor...
public FeedManager(IFeed[] feeds) {...}
or if you want to add a little flare for calling the constructor directly...
public FeedManager(params IFeed[] feeds) {...}
Assuming you want to determine the actual concrete instances at runtime, you need to use named type registrations and then tell unity which one you want. So, use a factory method to construct the types required and pass those in as parameter overrides. Unity will use the overrides and resolve any remaining dependencies.
// register the types using named registrations
container.RegisterType<IFeedManager,FeedManager>()
container.RegisterType<IFeed, Feed1>("Feed1")
container.RegisterType<IFeed, Feed2>("Feed2")
Assuming your feed manager has the following named constructor parameters
class FeedManager : IFeedManager
{
public FeedManager (IFeed Feed1, IFeed Feed2, string someOtherDependency)
{
}
}
and create your feed manager:
static IFeedManager CreateFeedManager()
{
ParameterOverride feed1 = new ParameterOverride("Feed1"
,_container.Resolve<IFeed>("feed1"));
ParameterOverride feed2 = new DependencyOverride("Feed2"
,_container.Resolve<IFeed>("feed2"));
IFeedManager = _container.Resolve<IFeedManager>(feed1,feed2)
return IFeedManager;
}
Obviously this is overly simplified, but you you insert your own logic to determine which instance is to be resolved and then injected for each of the IFeed instances required by the FeedManager.
With Unity you would do this like so:
container.RegisterType<IFeed, Feed1>("Feed1");
container.RegisterType<IFeed, Feed2>("Feed2");
container.RegisterType<FeedManager>(new InjectionConstructor(new ResolvedParameter<IFeed>("Feed1"),
new ResolvedParameter<IFeed>("Feed2")));
This has now configured Unity so that when it needs to resolve a FeedManager, it will resolve Feed1 for the first parameter and Feed2 for the second parameter.
This is a simple questions. I have researched this questions in my notebooks and books and the internet but cant find an answer
Why would we override the default constructor by adding parameters to it?
You would create a constructor for a class to manipulate its member variables according to whatever other conditions as soon as it's created. I get the impression you don't actually know what a constructor is.
Many languages (like C++/C#/Java) automatically create default no-arguments constructor when none defined in the class explicitly.
When you create a constructor in a class with or without arguments usually compiler stop creating default auto-generated constructor (depending on language specification). This is done on assumption if you have some non default initialization than automatically generated one is likely to not create object in a state you would expect.
Since having constructor with arguments is natural way to create objects it is essentially lead to "removing" default auto-generated constructor which probably can be called "overriding default constructor".
Is it possible to make unity try all defined constructors starting with the one with most arguments down to the least specific one (the default constructor)?
Edit
What I mean:
foreach (var constructor in concrete.GetConstructorsOrderByParameterCount())
{
if(CanFulfilDependencies(constructor))
{
UseConstructor(constructor);
break;
}
}
I don't want Unity to only try the constructor with most parameters. I want it to continue trying until it finds a suitable constructor. If Unity doesn't provide this behavior by default, is it possible to create an extension or something to be able to do this?
Edit 2
I got a class with two constructors:
public class MyConcrete : ISomeInterface
{
public MyConcrete (IDepend1 dep, IDepend2 dep2)
{}
public MyConcrete(IDepend1 dep)
{}
}
The class exists in a library which is used by multiple projects. In this project I want to use second constructor. But Unity stops since it can't fulfill the dependencies by the first constructor. And I do not want to change the class since the first constructor is used by DI in other projects.
Hence the need for Unity to try resolving all constructors.
Unity will choose the constructor with the most parameters unless you explicitly tag a constructor with the [InjectionConstructor] attribute which would then define the constructor for Unity to use.
When you state a suitable constructor; that is somewhat contingent on the environment. If for instance you always want to guarantee that a certain constructor is used when making use of Unity use the attribute mentioned previously, otherwise explicitly call the constructor you want to use.
What would be the point of Unity "trying" all constructors? It's purpose is to provide an instance of a type in a decoupled manner. Why would it iterate through the constructors if any constructor will create an instance of the type?
EDIT:
You could allow the constructor with the most params to be used within the project that does not have a reference to that type within its container by making use of a child container. This will not force the use of the constructor with a single param but it will allow the constructor with 2 params to work across the projects now.
You could also switch to using the single constructor across the board and force the other interface in via another form of DI (Property Injection), not Constructor Injection...therefore the base is applicable across the projects which would make more sense.