Safe mode in D?

[Paulo Pinto]

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