Ever since I was introduced to Java during my internship at IBM, I have been fascinated about the concept of Reflection. The only way something like that was possible in C/C++ was to put a function in a DLL and use GetProcAddress(), which we all know can get real dirty. But with Reflection things are real smooth and way more powerful. Without that you think the IDEs would have been this awesome?
Anyways this fascination continued at my first work place, National Instruments, where I started working with .NET. But it was not until today that I was aware of a competitor to this Reflection in .NET. That is the TypeDescriptor. Things can just keep getting more and more awesome with these managed frameworks. First they came up with Reflection, which just exposed any type from any assembly. This probably made the Type designer think that their types were lying around bare in front of their users. They saw the types struggling to cover themselves, hiding and crying. The scene was like the regime of an evil master/demon. But God protects the weak and the prayers of the Type and Type designers were answered. The framework developers finally decided to shield these poor and shy Types from their consumers and that is when they came up with this "TypeDescriptor" funda.
With this TypeDescriptor leading the troops from the front, Type and Type designers could combat the evil. If Reflection was like the nuclear energy in the hands of the evil, TypeDescriptor was like the lead container used to put the nuclear radiations under control. I mean, with TypeDescriptor we can decide what the type will look like to other people when looked through the TypeDescriptor. So if we have to protect our types we have to con the users into looking through this Descriptor and not the old weapon.
If TypeDescriptor is under use with a type, it expects that particular type to throw open some methods which the TypeDescriptor can use to give some information about the type. Later on this information is passed on to our users. And the obvious way of providing this methods is through interface and an example is ICustomTypeDescriptor. And if I remember correctly, just like assigning a TypeConverter to a type we can probably assign a TypeDescriptor also which takes care of presenting the type to the outside world.
But you know what, if your type does not have a custom type descriptor, or has a very lazy one - meaning one that just forwards the calls to the default one, then the shield no longer works. Because if the TypeDescriptor does see any openings to get information about the type, it goes for the inevitable --- Reflection.
So go protect your types, and don't forget the conning part.
In another post I will be more technical and less a story teller and write about the implementation of this TypeDescriptor.
--- Hari Om.
Anyways this fascination continued at my first work place, National Instruments, where I started working with .NET. But it was not until today that I was aware of a competitor to this Reflection in .NET. That is the TypeDescriptor. Things can just keep getting more and more awesome with these managed frameworks. First they came up with Reflection, which just exposed any type from any assembly. This probably made the Type designer think that their types were lying around bare in front of their users. They saw the types struggling to cover themselves, hiding and crying. The scene was like the regime of an evil master/demon. But God protects the weak and the prayers of the Type and Type designers were answered. The framework developers finally decided to shield these poor and shy Types from their consumers and that is when they came up with this "TypeDescriptor" funda.
With this TypeDescriptor leading the troops from the front, Type and Type designers could combat the evil. If Reflection was like the nuclear energy in the hands of the evil, TypeDescriptor was like the lead container used to put the nuclear radiations under control. I mean, with TypeDescriptor we can decide what the type will look like to other people when looked through the TypeDescriptor. So if we have to protect our types we have to con the users into looking through this Descriptor and not the old weapon.
If TypeDescriptor is under use with a type, it expects that particular type to throw open some methods which the TypeDescriptor can use to give some information about the type. Later on this information is passed on to our users. And the obvious way of providing this methods is through interface and an example is ICustomTypeDescriptor. And if I remember correctly, just like assigning a TypeConverter to a type we can probably assign a TypeDescriptor also which takes care of presenting the type to the outside world.
But you know what, if your type does not have a custom type descriptor, or has a very lazy one - meaning one that just forwards the calls to the default one, then the shield no longer works. Because if the TypeDescriptor does see any openings to get information about the type, it goes for the inevitable --- Reflection.
So go protect your types, and don't forget the conning part.
In another post I will be more technical and less a story teller and write about the implementation of this TypeDescriptor.
--- Hari Om.
No comments:
Post a Comment