I went through all the posts on reflection but couldn't find the answer to my question.
What were the problems in the programming world before .NET reflection
came and how it solved those problems?
Please explain with an example.
It should be stated that .NET reflection isn't revolutionary - the concepts have been around in other framework.
Reflection in .NET has 2 facets:
Investigating type information
Without some kind of reflection / introspection API, it becomes very hard to perform things like serialization. Rather than having this provided at runtime (by inspecting the properties/fields/etc), you often need code-generation instead, i.e. code that explicitly knows how to serialize each of your types. Tedious, and painful if you want to serialize something that doesn't have a twin.
Likewise, there is nowhere to store additional metadata about properties etc, so you end up having lots of additional code, or external configuration files. Something as simple as being able to associate a friendly name with a property (via an attribute) is a huge win for UI code.
Metaprogramming
.NET reflection also provides a mechanism to create types (etc) at runtime, which is hugely powerful for some specific scenarios; the alternatives are:
essentially running a parser/logic tree at runtime (rather than compiling the logic at runtime into executable code) - much slower
yet more code generation - yay!
I think to understand the need for reflection in .NET, we need to go back to before .NET. After all, modern languages like like Java and C# do not have a history BF (before reflection).
C++ arguably has had the most influence on C# and Java. But C++ did not originally have reflection and we coded without it and we managed to get by. Occasionally we had void pointer and would use a cast to force it into whatever type we wanted. The problem here was that the cast could fail with terrible consequences:
double CalculateSize(void* rectangle) {
return ((Rect*)rectangle)->getWidth() * ((Rect*)rectangle)->getHeight());
}
Now there are plenty of arguments why you shouldn't have coded yourself into this problem in the first place. But the problem is not much different from .NET 1.1 with C# when we didn't have generics:
Hashtable shapes = new Hashtable();
....
double CalculateSize(object shape) {
return ((Rect)shape).Width * ((Rect)shape).Height;
}
However, when the C# example fails it does so with a exception rather than a potential core dump.
When reflection was added to C++ (known as Run Time Type Identification or RTTI), it was hotly debated. In Stroustrup's book The Design and Evolution of C++, he lists the following
arguments against RTTI, in that some people:
Declared the support unnecessary
Declared the new style inherently evil ("against the spirit of C++")
Deemed it too expensive
Thought it too complicated and confusing
Saw it as the beginning of an avalanche of new features
But it did allow us to query the type of objects, or features of objects. For example (using C#)
Hashtable shapes = new Hashtable();
....
double CalculateSize(object shape) {
if(shape is Rect) {
return ((Rect)shape).Width * ((Rect)shape).Height;
}
else if(shape is Circle) {
return Math.Power(((Circle)shape).Radius, 2.0) * Math.PI;
}
}
Of course, with proper planning this example should never need to occur.
So, real world situations where I've needed it include:
Accessing objects from shared memory, all I have is a pointer and I need to decide what to do with it.
Dynamically loading assemblies, think about NUnit where it loads every assembly and uses reflection to determine which classes are test fixtures.
Having a mixed bag of objects in a Hashtable and wanting to process them differently in an enumerator.
Many others...
So, I would go as far as to argue that Reflection has not enabled the ability to do something that couldn't be done before. However, it does make some types of problems easier to code, clearer to reader, shorter to write, etc.
Of course that's just my opinion, I could be wrong.
I once wanted to have unit tests in a text file that could be modified by a non-technical user in the format in C++:
MyObj Function args //textfile.txt
But I couldn't find a way to read in a string and then have the code create an object instance of the type represented by the string without reflection which C++ doesn't support.
char *str; //read in some type from a text file say the string is "MyObj"
str *obj; //cast a pointer as type MyObj
obj = new str; //create a MyObj
Another use might be to have a generic copy function that could copy the members of an class without knowing them in advance.
It helps a lot when you are using C# attributes like [Obsolete] or [Serializable] in your code. Frameworks like NUnit use reflection on classes and containing methods to understand which methods are tests, setup, teardown, etc.
Related
Intro
To create instances on the fly via reflection, we could use:
Activator.CreateInstance
The downside to this is that this returns an object, while I really need the concrete type and since I only know the runtime type I can't cast.
To accomplish this, we can use
Activator.CreateInstance<T>
Which returns a T, but since I don't know T at compile time, this is no use either. At first glance anyway.
Currently I'm using dynamic for this, in a special kind of way:
//I pass the runTimeType as an ITopSecret
// runTimeType implements ITopSecret
dynamic concreteTypeInstance = Activator.CreateInstance(runTimeType);
// Now we just have an empty RunTimeType.
// I can use the passed runTimeType to fill the newly created object
concreteTypeInstance = runTimeType
// Then I call ApplyCurrentValues.
// Can't pass runTimeType, because it's ITopSecret and
// EF doesn't figure out the actual runtime type.
context.ApplyCurrentValues(concreteTypeInstance)
Before this line some sanity checks are performed. For example I know the runtime type is always a certain ITopSecret at this point, otherwise the statement can't get hit.
So presumably this is reasonably safe. It does exactly what I want, with 1 line of code, which seems great.
However I'm not sure this is the intended way of using dynamic and if I'm setting the door open for nasty stuff.
Why do I want this
Currently we have 1000s of lines of boilerplate code in many Update methodes across various services. This is handcrafted, thus error-prone, repetetive, violates DRY and makes it harder for new people.
Furthermore this makes the methods unclear by losing focus on business logic and, frankly, is just plain ugly. All the usual suspects ;)
So I'm writing some abstract/generic code to factor out all that repetitive stuff. Which is a very nice and cool bit of software to write, but leaves me with (mostly) runtime info.
Under the surface these methods all use Entity Framework and its ApplyCurrentValues method. This method requires a concrete, instantianted, type and hence my questions.
Hope this is clear enough :)
Questions
Is this an OK way to use dynamic, considering I perform do some sanity checks before actually using it?
I feel that there's a way using reflection to accomplish this. That might be worse in terms of performance, but I'm very curious if this can be done.
Is it possible to create the generic Activator.CreateInstance<T> using reflection?
Are either possibilities bad and should I take a different approach entirely?
However not knowing the concrete types at run-time, but needing them anyway is not something I can move away from.
I am using ILNumerics to represent some time series.
Ideally I would like to have all data incapsulated a la object oriented and, therefore, to use instance variables and instance methods to process such variables.
I have several questions, but all related to what is the best way to implement ILArray in a class, in an efficient way and, possibly, as instance variables. I have gone through the relevant documentation and checked previous SO examples, but none seems to explicitly address these issues.
First: the example proposed on the website for 'Array Utilization Class'
[source: http://ilnumerics.net/ClassRules.html] does not seem to compile, at least with ILNumerics trial edition and VS 2013 professional (.net 4.5). Am I missing something?
Or is it because this part of the code:
public ILRetArray<double> A
{
get
{
// lazy initialization
if (m_a.IsEmpty)
{
m_a.a = ILMath.rand(100,100);
}
}
set { m_a.a = value; }
does not have a return statement?
In the mentioned example then the m_a array may be modified through the following instance method:
public void Do()
{
using (ILScope.Enter())
{
// assign via .a property only!
m_a.a = m_a + 2;
}
}
How can one access a specific component of the vector: suppose we want something like
m_a[0] = 2.2; would this get in the way of the memory management?
As a general observation, it would seem to me that the natural way of using ILNumerics is through static methods as one would write the code in Fortran (or possibly in R/Matlab): this is how I have used it, so far. Am I right or class definition having ILArray types as instance variables and relevant methods should be as efficient and straightforward?
Alternatively, would you recommend adopting System arrays as instance variables and then importing/exporting to ILarray only through static methods to perform array operation? I would tend to avoid this path or I would like to keep it as confined as possible.
The documentation section 'ILArray and Classes' has been updated. As you stated, there was a mistake in the sample code.
Modifying ILArray instances as Class Member
By following the rules described in the documentation, all array members will be of type ILArray (or ILLogical or ILCell). These types are mutable types. You can alter them freely during their lifetime. m_a[0] = 2.2; works as expected. You may also decide to replace the array completely:
m_a.a = ILMath.rand(2,3,5);
Just keep in mind, not to simply assign to the array but to use the .a = property or .Assign() method on the array. The compiler will prevent you from mistakenly assigning anyway, since you have declared your array as readonly.
Such alteration does work with the memory management smoothly.
Mixing Static Methods and Class Instances
As long as you keep an eye on the rules for both: functions (ILScope blocks, distinct input parameter array types, assignemens via .a property) and classes (readonly ILArray<T> declaration, ILMath.localMember<T> initialization) you can freely mix both schemes. It will work both ways and reuse all memory not needed anymore immediately.
Mixing intensive use of System.Array with ILArray<T> on the other side may lead to disadvantageous allocation patterns. In general, it is easy to create ILArray from System.Array. The System.Array will be used directly by the ILArray if it fits into the storage scheme (i.e. if it is 1dimensional). But the other way around is not very efficient. It generally involves a copy of the data and the ILNumerics memory management cannot work efficiently either.
That's why we recommend to stay with ILArray and the like. As you see, there are some rules to keep in mind, but usually you will internalize them very quickly.
I inherited some source code that I am just starting to dig though, and i found the previous owner has made some use of the using directive as an alias for a List<T>, but I've never seen this specific approach before.
namespace MyNamespace
{
using pType1 = List<type1>;
using pType2 = List<List<type1>>;
// classes here
}
Both of these elements are used quite heavily within the code and are also return types from several of the key methods within the code. I get what he was trying to accomplish with using a simple name rather than repeating List<type1> and List<List<type1>> over and over again. I'm debating whether to create a real type to replace the using statements, but before i spend the time, I was wondering if there were any pros/cons to keeping the current implementation.
Generally, if a data structure represents some entity in your application's domain model it should get its own type; it makes the code much clearer and understandable. On the other hand, if you just need a List<List<string>> for intermediate data processing there's no real benefit in making a proper type for that.
In your case, since the original dev went to the trouble of making an alias for the type it's logical that it would be used a lot, which points to the "represents an entity" scenario. If so, definitely go ahead and create a new type for the structure (possibly something more appropriate than bare lists and usually something defined in terms of interfaces rather than concrete classes, but that depends on what you 're actually modelling there).
If that construct is used as heavily as you say, I would definitely replace it with (the) real types (explicitly write out the List or create a new type). If someone happens to change one of the type declarations, like
using pType1 = List<type2WhichType1InheritsFrom>;
because (s)he thinks the base version does something better without looking at all places where it is used, there might be some unwanted side effects.
I recently began to start using functions to make casting easier on my fingers for one instance I had something like this
((Dictionary<string,string>)value).Add(foo);
and converted it to a tiny little helper function so I can do this
ToDictionary(value).Add(foo);
Is this against the coding standards?
Also, what about simpler examples? For example in my scripting engine I've considered making things like this
((StringVariable)arg).Value="foo";
be
ToStringVar(arg).Value="foo";
I really just dislike how inorder to cast a value and instantly get a property from it you must enclose it in double parentheses. I have a feeling the last one is much worse than the first one though
Ignoring for a moment that you may actually need to do this casting - which I personally doubt - if you really just want to "save your fingers", you can use a using statement to shorten the name of your generic types.
At the top of your file, with all the other usings:
using ShorterType = Dictionary<string, Dictionary<int, List<Dictionary<OtherType, ThisIsRidiculous>>>>;
I don't think so. You've also done something nice in that it's a bit easier to read and see what's going on. Glib (in C) provides casting macros for their classes, so this isn't a new concept. Just don't go overkill trying to save your fingers.
In general, I would consider this to be code smell. In most situations where the type of casting you describe is necessary, you could get the same behavior by proper use of interfaces (Java) or virtual inheritance (C++) in addition to generics/templates. It is much safer to leave that responsibility of managing types to the compiler than attempting to manage it yourself.
Without additional context, it is hard to say about the example you have included. There are certainly situations in which the type of casting you describe is unavoidable; but they're the exception rather than the rule. For example, the type of casting (and the associated helper functions/macros) you're describing extremely common-place in generic C libraries.
I'm looking at OCaml's functors. It looks to me pretty identical to the so called generic objects in C++/C#/Java. If you ignore Java's type erasion for now, and ignore the implementation details for C++ templates (I'm interested with the language feature), functors are quite indentical to generics.
If I understand it correctly, functor gives you a new set of functions from a type you provide, so that for example
List<MyClass>.GetType() != List<MyOtherClass>.GetType()
But you could roughly rewrite OCaml's
#module Set =
functor (Elt: ORDERED_TYPE) ->
struct
type element = Elt.t
type set = element list
let empty = []
let rec add x s =
match s with
[] -> [x]
| hd::tl ->
match Elt.compare x hd with
Equal -> s (* x is already in s *)
| Less -> x :: s (* x is smaller than all elements of s *)
| Greater -> hd :: add x tl
let rec member x s =
match s with
[] -> false
| hd::tl ->
match Elt.compare x hd with
Equal -> true (* x belongs to s *)
| Less -> false (* x is smaller than all elements of s *)
| Greater -> member x tl
end;;
into C#
class Set<T> where T : ISortable
{
private List<T> l = new List<T>();
static public Set<T> empty = new Set<T>();
public bool IsMember(T x) {return l.IndexOf(x) > -1;}
public void Add(T x) {l.Add(x);}
}
Sure there's a slight different since a functor affects a Module (which is just a bunch of types function and values definitions, similar to C#'s namespace).
But is it just it? Are functors merely generics applied to namespaces? Or is there any signifcant different between functors and generics which I'm missing.
Even if functors are just generics-for-namespace, what's the significant advantage of that approach? Classes can also be used as ad-hoc namespaces using nested classes.
But is it just it? Are functors merely
generics applied to namespaces?
Yes, I think one can treat functors as "namespaces with generics", and that by itself would be very welcome in C++ where the only option left is to use classes with all static members which becomes pretty ugly soon. Comparing to C++ templates one huge advantage is the explicit signature on module parameters (this is what I believe C++0x concepts could become, but oops).
Also modules are quite different from namespaces (consider multiple structural signatures, abstract and private types).
Even if functors are just
generics-for-namespace, what's the
significant advantage of that
approach? Classes can also be used as
ad-hoc namespaces using nested
classes.
Not sure whether it qualifies for significant, but namespaces can be opened, while class usage is explicitly qualified.
All in all - I think there is no obvious "significant advantage" of functors alone, it is just different approach to code modularization - ML style - and it fits nicely with the
core language. Not sure whether comparing module system apart from the language makes much sense.
PS C++ templates and C# generics are also quite different so that comparing against them as a whole feels little strange.
If I understand it correctly, functor gives you a new set of functions from a type you provide
More generally, functors map modules to modules. Your Set example maps a module adhering to the ORDERED_TYPE signature to a module implementing a set. The ORDERED_TYPE signature requires a type and a comparison function. Therefore, your C# is not equivalent because it parameterizes the set only over the type and not over the comparison function. So your C# can only implement one set type for each element type whereas the functor can implement many set modules for each element module, e.g. in ascending and descending order.
Even if functors are just generics-for-namespace, what's the significant advantage of that approach?
One major advantage of a higher-order module system is the ability to gradually refine interfaces. In OOP, everything is public or private (or sometimes protected or internal etc.). With modules, you can gradually refine module signatures at will giving more public access closer to the internals of a module and abstracting more and more of it away as you get further from that part of the code. I find that to be a considerable benefit.
Two examples where higher-order module systems shine compared to OOP are parameterizing data structure implementations over each other and building extensible graph libraries. See the section on "Structural abstraction" in Chris Okasaki's PhD thesis for examples of data structures parameterized over other data structures, e.g. a functor that converts a queue into a catenable list. See OCaml's excellent ocamlgraph library and the paper Designing a Generic Graph Library using ML Functors for an example of extensible and reusable graph algorithms using functors.
Classes can also be used as ad-hoc namespaces using nested classes.
In C#, you cannot parameterize classes over other classes. In C++, you can do some things like inheriting from a class passed in via a template.
Also, you can curry functors.
Functors in SML are generative, so the abstract types produced by an application of a functor at one point in a program are not the same as the abstract types produced by the same application (i.e. same functor, same argument) at another point.
For example, in:
structure IntMap1 = MakeMap(Int)
(* ... some other file in some other persons code: *)
structure IntMap2 = MakeMap(Int)
You can't take a map produced by a function in IntMap1 and use it with a function from IntMap2, because IntMap1.t is a different abstract type to IntMap2.t.
In practice this means if your library has a function producing an IntMap.t then you must also supply the IntMap structure as part of your library, and if the user of your library wants to use his own (or another libraries) IntMap then he has to convert the values from your IntMap to his IntMap - even though they are already structurally equivalent.
The alternative is to make your library a functor itself, and require the user of the library to apply that functor with their choice of IntMap. This also requires the user of the library to do more work than ideal. Especially when your library not only uses IntMap, but also other kinds of Map, and various Sets, and others.
With generics, OTOH, it is quite easy to write a library producing a Map, and have that value work with other libraries functions that take Map.
I just found a source that may help you with your problem - as OCaml has a different meaning for functors:
http://books.google.de/books?id=lfTv3iU0p8sC&pg=PA160&lpg=PA160&dq=ocaml+functor&source=bl&ots=vu0sdIB3ja&sig=OhGGcBdaIUR-3-UU05W1VoXQPKc&hl=de&ei=u2e8SqqCNI7R-Qa43IHSCw&sa=X&oi=book_result&ct=result&resnum=9#v=onepage&q=ocaml%20functor&f=false
still - I find it confusing if the same word is used for different concepts.
I don't know if OCaml has a different meaning - but normally a Functor is a "Function object" (see here: http://en.wikipedia.org/wiki/Function_object). This is totally different to generics (see here: http://en.wikipedia.org/wiki/Generic_programming)
A function object is an object that can be used as a function. Generics are a way to parametrize objects. Generics are kind of orthogonally to inheritance (which specializes objects). Generics introduce typesafety and reduce the need for casting. Functors are an improved function pointer.