Agree looking at what its used for is the best .. in most cases here is
where i see it being used ( in the CLR) - excluding debugging / code
browsing
In order of importance.
1) Having a string in a config file and creating that type ..which is
treated in code via an interface
2) Being able to act on any property eg ORM / Serializer / Mappers acting
on all public properties of an object and matching them by name / type.
3) Non type safe dynamic code... The new C# (dynamic) keyword removed
quite a bit of this by forcing a run time type check.
4) Accessing encapsulated / private data / functions . This comes in
several flavours
- Full Serialization
- For testing etc Unit Testing / mocking is an important
case here.
- To overcome the lack of "friend" , but with assemblies
you can at least expose internals to a testing Lib .
5) Performance - in most cases reflection has very poor performance but
sometimes creating your own type can be better eg baking strongly typed
delegates vs runtime checks.
In most cases its a big hack which should not be needed if
1) there is a safe way to create a type from a config file / message
string which is then accessed through an abstracted type.
2) Some way to iterate through public properties and check their name/
value/ type or a system function that does that or copies those objects to
another object of a different type. Though i don't see how this can nicely
be done.
3) You have some sort of dynamic typing with run time checks via a cast /
method param ..
4) You have some sort of friend / expose Internals to concept.
Note here it is a case of laziness you could force the implementation of
interfaces such as ISerialiseable but people want an easier way .. So
you really want to serialize ANY object ..or copy an object .
I see no strong reason for self modification of code .
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
