Reflection and access-modifiers

  • Thread starter Thread starter Picho
  • Start date Start date
P

Picho

Hi all,

Using reflection, I can invoke/call private methods of an object.

is this intended?
if yes, why? in what scenario (example would be good) should I be givven the
option to use something that was declared private (not public) and not mine
to use? seems to me this is somewhat malicious...
if not.... well....

Thanx,
Picho
 
Yes its intended - its how the System.Runtime.Serialization infrastructure works for example

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi all,

Using reflection, I can invoke/call private methods of an object.

is this intended?
if yes, why? in what scenario (example would be good) should I be givven the
option to use something that was declared private (not public) and not mine
to use? seems to me this is somewhat malicious...
if not.... well....

Thanx,
Picho
 
Yes, this is intentional and it's necessary for a number of aspects of .NET
to function properly.

Remember, things like private and protected are generally language specific
issues, so you could very well write a language that didn't use access
modifiers and didn't respect them in the framework or other .NET software.
On the other hand, I wouldn't recommend using it willy-nilly.

There have actually been times where I've used it to bypass what I would
consider bad design choices by MS, to get at functionality in the underlying
framework that I otherwise couldn't. But I would not expect that code to
work in future versions of .NET, so consider doing stuff like that to be
non-portable and generally unsafe.

Pete
 
Pete Davis said:
Yes, this is intentional and it's necessary for a number of aspects of .NET
to function properly.

Remember, things like private and protected are generally language specific
issues, so you could very well write a language that didn't use access
modifiers and didn't respect them in the framework or other .NET software.
Click to expand...

I don't believe that's true - unless you are running in a full trust
environment.

While there are some access modifiers (I can't remember which off-hand,
unfortunately) which are more "advisory" than compulsory, I believe
most will be enforced by the CLR, at least when running in anything
other than full trust, and especially with verification on.

Note that without ReflectionPermission, you can't access non-public
methods via reflection either.
 
I apologize, I should have been more clear. My meaning was, one could create
a language that ignored access modifiers by using reflection to call methods
that would otherwise be prohibited. You are correct, of course, that the CLR
will enforce access modifiers and that you'd need reflection permissions.

This has no been my day. My head has been in a cloud since I woke up. I
apologize for not being more clear.
 
Back
Top