Not really sure what to say about this, we can either guard against recursion or not, I see no reason *not* to guard against recursion except that it could allow unauthorized direct
access when the guard is active.
I guess a third option could be that if the property is attempted to be accessed while being guarded and that access is not from within the accessor, then it issues a warning (or not)
and returns NULL. Thoughts? On 1/3/2013 4:43 PM, Stas Malyshev wrote:
Hi!I think infinite recursion is a potential issue for lots of logging setups ("let's log when someone calls the logger!") and situations where you have multiple values to keep in sync. The accessor implementation shouldn't try to solve these design problems.The whole problem here is that the only reason why it is a problem is because of the accessors that have hidden state in guards. If it were regular variables (and for all the API consumer knows, they are) there wouldn't be any question about if we're allowed to read $user->username or not - if it's public, of course we can read it. So the problem exists because the hidden state exists. It's not the problem of the code that uses public APIs in completely legal way, it is the problem of our implementation that we have hidden state that changes how variable access works. With __get we mostly ignored it since recursion blocker leads to the same result as if the variable did not exist - which is the case for __get anyway, kind of - so it was less explicit. With accessors it may become more painful.
-- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
