On 1/3/13 1:48 AM, Stas Malyshev wrote:
class SuperDate {
        private $date {
                get;
                set(DateTime $x) { $this->date = $x; $this->timestamp =
$x->getTimestamp();
        }
        private $timestamp {
                get;
                set($t) { $t = (int)$t; $this->timestamp = $t; $this->date = new
DateTime("@$t"); }
        }
}

What happens to it? Would it get into infinite loop or will just set the
value twice? What would be the correct way to write such a code (note

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.


class UserContext {
        protected $user;
        public $logger;
        public $username {
                get() { $this->logger->log("Getting username"); return 
$user->name; }
                set($n) { $this->user = User::get_by_name($n); }
        }
}

class Logger {
        protected $ctx;
        public function __construct(UserContext $ctx) {
                $this->ctx = $ctx;
                $this->logfile = fopen("/tmp/log", "a+");
        }
        public function log($message) {
                fwrite($this->logfile, "[$this->ctx->username] $message\n");
        }
}

$u = new UserContext();
$u->logger = new Logger($u);
$u->username = "johndoe";
echo $u->username;

What would happen with this code? Will the log be able to log the actual
user name, and if not, how you protect from such thing? $username is a
part of public API of UserContext, so whoever is writing Logger has
right to use it. On the other hand, whoever is using logger->log in
UserContext has absolutely no way to know that Logger is using
ctx->username internally, as these components can change completely
independently and don't know anything about each other besides public APIs.
What I am getting at here is that shadowing seems to create very tricky
hidden state that can lead to very bad error situations when using
public APIs without knowledge of internal implementation.

Again, the problem is not shadowing (not even in use here) but really general information hiding. You can create these problems anytime you have hidden information and interdependent objects, and it's an API design problem.

Steve Clay
--
http://www.mrclay.org/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to