Am 19.10.2013 17:09, schrieb Max Samukha:
On Saturday, 19 October 2013 at 10:50:42 UTC, Maxim Fomin wrote:
OK, you can remove extern(c) trick (however, it is not clear, why it
shouldn't be counted as a type system hole) and you still have
"reflection hole".
I came up with the code in response to Andrei who said that
constructor control flow is "primitive but quite adequate" and which
"is already implemented and works". What "primitive but quite
adequate" does mean is subjective, but it does not really prevent from
what it is suppose to prevent. Of course in this case you do not
corrupt memory or write to immutable (I am telling this for the third
time). The point was made why would you have such constraint if it is
easily avoidable? How much sense is in the constraint which does not
provide real value (except probably as an exercise in implementing
abstract programming theories from academia) nor is properly reinforced?
The question is what it takes to close every possible hole. .NET
designers apparently decided not to close the reflection hole because
the cost (in various senses) would be too high.
Actually it is very practical, even Java allows for the same functionality.
The ability to disable the security manager and use reflection to access
stuff one should actually not be aware of, is a very handy to do unit
testing with badly designed libraries.
For example, most Sitecore code uses static classes everywhere.
So either you replicate the whole Sitecore API on both sides
(consumer/producer code) to be able to mock all required classes. Or use
dirty reflection tricks to rebind method calls, even for private ones.
Too dirty I know, but enterprise code is never pretty.
--
Paulo
