Is there any plan to more generally support duck/structural/extensional typing? -- you already support this in your API for finding c'tors automatically based on names and types.
For example, the following API:
StructurallyImplements( typeOrInstance, list of instances or types...)
would return true if the type or instance on the left supports the instances/classes/interfaces on the right, but using nominal/structural testing only.
interface IID { int ID get; }
// returns true, even though the anon obj doesn't support the named interface
StructurallyImplements( new {ID=3}, IID);
// returns true because the type of the right "covers" the type on the left
StructurallyImplements( new {ID=3, Name="Joe"}, new {ID=3, Name="Sam", Age=42} );
// returns false because all types on the right are not supported
StructurallyImplements( new {ID=3, Age="42"}, new {ID=3, Name="Sam"});
// returns false because all types on the right are not supported
StructurallyImplements( new {ID=3, Name="Joe"}, new {ID=3, Name="Sam"}, IAddress );
This should be simple to implement given your current API, but wondering if it's useful to include.
Now, as far as creating a fast proxy that will create a concrete instance of a named class from an untyped DTO once compatibility is ensured, I guess that's something you don't want to take on in your lib -- as I recall there are a few of these around, but I haven't looked in a while.
Is there any plan to more generally support duck/structural/extensional typing? -- you already support this in your API for finding c'tors automatically based on names and types.
For example, the following API:
StructurallyImplements( typeOrInstance, list of instances or types...)would return true if the type or instance on the left supports the instances/classes/interfaces on the right, but using nominal/structural testing only.This should be simple to implement given your current API, but wondering if it's useful to include. Now, as far as creating a fast proxy that will create a concrete instance of a named class from an untyped DTO once compatibility is ensured, I guess that's something you don't want to take on in your lib -- as I recall there are a few of these around, but I haven't looked in a while.