3

The question rises with two facts: 1) With reflection it is possible to call private method. 2) TypeBuilder can't build new type "inherited" form internal type from another assembly.

I can explain TypeBuilder behavior using ECMA-335 - If type is not "marked as exported" it is invisible, inheritance require visibility.

But I can't explain why reflection works?

ECMA specification legalize metadata accessing at run-time using Reflection, and one application is mentioned - serialization, that means access to the state, to the fields.. There are also sentence "metadata describes how to resolve call", but I can't find cases in the text where method's accessibility can be ignored resolving the call. Possibly I miss something. Could somebody explain me the way how ECMA authors left the door opened for private method calls (at least for reflection, btw there are phrase "members accessibilities can be ignored if it is specialy specified" - but I can't find those cases in the text, again)?

Roman Pokrovskij
  • 9,449
  • 21
  • 87
  • 142
  • I know about http://stackoverflow.com/questions/2084353/why-reflection-can-access-protected-private-memeber-of-class-in-c , I think my question is different. – Roman Pokrovskij Nov 23 '10 at 02:09

1 Answers1

2

Just a guess here, but static analysis for things like verifying type safety and trustworthiness of managed code requires looking at all parts of a class type - the public interface as well as the private fields. If a class contains a private field that is an unsafe type, the type safety of the class itself is in question.

If private members were not visible in the reflection API, static analysis for type safety would not be possible, or would be woefully incomplete.

dthorpe
  • 35,318
  • 5
  • 75
  • 119
  • But I still see the huge difference between the call and the "description how to call"... also can see much smaller difference between "to access/setup the state" and "to invoke the method". – Roman Pokrovskij Nov 23 '10 at 02:52