php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #55026 Document access to protected/private members using reflection
Submitted: 2011-06-10 15:36 UTC Modified: 2019-02-15 04:45 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: rasmus at mindplay dot dk Assigned:
Status: Open Package: Reflection related
PHP Version: 5.3.6 OS: Windows/Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-06-10 15:36 UTC] rasmus at mindplay dot dk
Description:
------------
Allow me to preface by saying, I am aware of bug #40348. I believe you made a mistake when, as the other reporter put it, you "corrected" that "bug" - in the following, I will attempt to explain and cite evidence from other languages, and software implemented on other platforms.

The ReflectionProperty::getValue() and ReflectionProperty::setValue() methods don't work for protected and private properties - they work only for public members, which makes them redundant, since you can already use simple syntax like $object->{$propertyName} to access public members.

The ReflectionMethod::invoke() method also does not work for protected and private methods - again, this only works for public members, which you can already invoke in other ways, making this method redundant.

I believe the idea behind reflection, is to enable the implementation of popular meta-programming patterns. In order to do this, the language provides access to things that your programs would otherwise have no knowledge of, such as property-types, argument lists, etc.

Another important aspect of property and method reflection, is to facilitate access to protected and private members.

While the reflection-classes will enable you to find protected and private members, the current implementation leaves your program with the knowledge of these members, but being unable to perform any operations on them. This awareness of the internals of a class, unfortunately, is useless - there is no meaningful operation you can perform based on this information.

The idea of allowing access to protected/private members, may seem counter-intuitive at first, but it is necessary. With reflection, you provided access to information that was "private" to the internal interpretation of the source-code by the programming language itself. In much the same way, and for the same reasons, you need to provide access to private members of user code.

While, theoretically, you could write terrible, incomprehensible code, by giving yourself read/write access to any property of any object, this is of course not why this feature exists in other languages - it exists to facilitate good, clean meta-programming.

An object-relational mapper, for example, would likely need access to protected and private members, in order to persist them to the database. In programming languages like C# and Java, this is possible, and enables (for example) Hibernate (and NHibernate on .NET) to persist protected and private members to the database.

Another example is debugging and diagnostic components, which would likely need access to protected and private members - and preferably not by contrived means, such as are necessary at the moment.

To cite precedence, the following unit test passes in C#:

        class Foo
        {
            public Foo()
            {
                Bar = 123;
            }

            private int Bar { get; set; }
        }

        [Test]
        public void CanAccessPrivateMembers()
        {
            var test = new Foo();

            // test.Bar = 456; // this is private and inaccessible

            var property = test.GetType().GetProperty("Bar", BindingFlags.Instance | BindingFlags.NonPublic);

            Assert.AreEqual(123, property.GetValue(test, null), "access to private member Foo.Bar");
        }

By using reflection to access private members, the programmer enters into an agreement - he should have the understanding that things can wrong when this feature is not used responsibly.

Documentation for this feature should be clear about the fact that access to private members is only typically useful for meta-programming. For example, when you are enumerating the properties of an object, and making decisions based on other available metadata. Documentation should clarify that this feature should not be "abused" as a means to forcibly get access to a specific member, since that would defeat the purpose of having protected/private members in the first place.

In conclusion, the removal of this feature was a mistake - reflection in PHP is currently crippled, and not as useful as it is in other languages.

Test script:
---------------
<?php

class Foo
{
  protected $bar = 123;
  
  protected function hello()
  {
    echo 'Hello, World';
  }
}

$object = new Foo;

var_dump($object);

$property = new ReflectionProperty('Foo', 'bar');

# var_dump($property->getValue($object)); // doesn't work

$method = new ReflectionMethod('Foo', 'hello');

# $method->invoke($object); // doesn't work


Expected result:
----------------
Both of the commented-out lines would cause the script to fail.

Uncommenting the first line, which should print '123', causes an exception.

Uncommenting the second line, should print 'Hello, World', but causes an exception.

Not demonstrated in this script is ReflectionProperty::setValue() which should also work.


Actual result:
--------------
Exceptions as described above.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-06-10 16:53 UTC] rasmus at mindplay dot dk
Okay, I guess I jumped the gun on this one - it turns out, this is possible, 
using the setAccessible() method.

http://de3.php.net/manual/en/reflectionproperty.setaccessible.php

So the following does work:

  $property = new ReflectionProperty('Foo', 'bar');
  $property->setAccessible(true);
  var_dump($property->getValue($object)); // does work

It appears that ReflectionMethod::setAccessible() was also added in 5.2 to the 
same end.

I believe it's a good thing to have to be very explicit about this in your code 
- having to indicate that you've understood what you're doing. Praise to whoever 
came up with that solution - it's actually better than what C# and others are 
doing.

However, the documentation is somewhat misleading:

"Sets a property to be accessible. For example, it may allow protected and 
private properties to be accessed."

I always understood this as meaning that it would actually change the visibility 
of an existing member - which would have been a rather destructive operation. It 
probably should more accurately read:

"Enables access to a protected or private property using the getValue() and 
setValue() methods, which would otherwise cause an exception."

In turn, the documentation for ReflectionProperty::getValue() and 
ReflectionProperty::setValue() needs to clarify this matter - something along 
the lines of:

"To enable access to private and protected properties, you must indicate your 
need to knowingly ignore the accessibility constraints of that property, by 
using the ReflectionProperty::setAccessible() method. Attempting to access a 
private or protected property without calling this method first, will cause an 
exception."

Similar documentation needs to be added for ReflectionMethod::setAccessible() 
and ReflectionMethod::invoke().
 [2011-06-10 16:57 UTC] rasmus at mindplay dot dk
-Summary: Access to protected/private members using reflection +Summary: Document access to protected/private members using reflection
 [2011-06-10 16:57 UTC] rasmus at mindplay dot dk
I'm changing the title and the bug-type to "Documentation Problem"
 [2019-02-15 04:45 UTC] carusogabriel@php.net
-Type: Feature/Change Request +Type: Documentation Problem
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Jul 18 20:01:26 2019 UTC