[PHP-RFC] Property Accessors 1.2 for Final Review before Vote View as Markdown

class Foo {
public $bar = 2 {
get;
set;
}
}

Consider properties not based on shadowed values:

class Foo {
private $realbar;

 public $bar = 2 {
     get { return $this->realbar; }
     set { $this->realbar = $value; }
 }

}

Here, initializing the shadow property is useless. It's similar to the case where you want
to have the initial value of a traditional property be the result of an expression (and
you can't because it would create a chicken-egg problem during construction).

Option 1: The most powerful solution I see is to have an init function that's implicitly
called before first access (and with direct write access to the shadow property if
needed). Consider trying to emulate the crazy document.cookie API:

class Document {
private $cookieProps;

 public $cookie {
     get { return /* based on cookieProps */; }
     set { /* set some cookieProps */ }

     // called implicitly before the first access (not before the constructor runs)
     // and would have direct access to the shadow property.
     init { /* set up cookieProps */ }
 }

}

Pros: can run any code necessary to initialize the property
Cons: must make a function just to have a default

Option 2: Keep the traditional syntax, but instead of always setting the shadow property,
call the setter with the given initial value directly before the first access.

Pros: familiar syntax; more expected behavior in some cases
Cons: what if there's no setter?; cannot run arbitrary setup code; setter can't
distinguish between a "user" set and the implicitly set before first access.

Option 3: A mix of both. The shadow property is always initialized with the value from the
traditional syntax. If needed, you can have an init that's called before first access.

Pros: For simple shadowed properties, just works as you'd expect and with familiar syntax;
Still allows robust initialization before first access if needed.
Cons: Author must remember that traditional syntax only useful for shadow prop.

Steve Clay

http://www.mrclay.org/

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.

__get()/__set() already implement infinite recursion guards, Accessors
are just doing the same thing.

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

--
-Clint

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.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Hi!

1. I tried to understand how the engine currently compiles and executes
   object property fetches. I found it to be incredibly complex and I
   certainly don't have the abilities to port this for statics. As such the
   "parent::$foo" syntax is dead unless someone else is going to do the
   necessary engine changes.

Object property fetches are not that hard, but parent::$foo is static
fetch - which is entirely different beast which uses different opcodes
and works differently. And is not supported by object handlers - mainly
because there's no object :) If we designed it from scratch, we could
probably make a class an object of type Class and probably avoided that
problem, since we could just use standard object handlers for that, but
it is not what currently happens. If somebody feels ambitious he may
explore that direction.

2. I think the "parent->foo" syntax is nice in concept, but I think that
   it's an absolute no-go as it doesn't fit in with the rest of PHP (and

Well, it partially does, since ->foo part works exactly like in any
other expression. But parent-> part and the whole dollar-less variable
seems foreign for me too, so I am not happy with this one either.

would still require some engine changes those complexity I can't really
estimate). The parent->foo syntax is some off mix between parent::$foo
(which makes sense) and $parent->foo (which also makes sense).

$parent->foo makes tons of sense, but it means there's an object called
$parent. Now the question is where this one came from?

3. My suggestion is to avoid the engine and syntax related issues of
   parent property access by putting this as a function in the standard
   library instead. What I'm thinking about is a function like
   get_parent_property() which returns the ReflectionProperty for it. Then
   you could do something like this:

This is an interesting approach. I like the idea of using the reflection
instead of inventing an awkward new syntax. However, I'm not sure I can
see how get_parent_property('foo') works - what exactly is 'foo' here?
Does it mean this function relies on implied $this? I'm not sure we
should be adding functions that do this. I'd rather have something like:
ReflectionProperty::getParentProperty($this, 'foo')

And yes, I know it's long-winded. But on the plus since it's generic,
does not pollute global space and might also be useful in other contexts.

Even more generic, we just could use existing ReflectionProperty like
this (this is standard API, no changes needed):

(new ReflectionProperty(get_parent_class(), 'foo'))->setValue($this, $val);

Yes, this is even more long-winded, that's why maybe we should have
shortcut function for it. Depends on how frequently in practice we
expect to do it.

I know that this is not an optimal solution, but I would much prefer
this over some new syntax like "parent->foo". Once (if) static

I like this approach more too.

properties have better engine support we can switch to the cleaner
parent::$foo way. But until then I think that this is a good compromise,

I'm afraid we couldn't though since parent::$foo already means something
else - it's a static property "$foo" of the class that is parent of
current class. We could redefine it in this specific context, in theory,
but that would be strange special case and I don't think it would be
good idea to do that. Our syntax kind of assumes the object has only one
class and all properties belong to this class, so we don't have a proper
syntax to express the idea of "same property, but with different scope".

This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could

If you assume current property you'd have to store it somewhere to pass
it and have API for that function to extract it, which sounds like very
tight coupling for this function. Maybe something like PROPERTY
would be better?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Why we must have parent property access at all? What's the use case and how do other langs do it?

Am I right to say there is no "parent property", this would just call the parent's [gs]etter using the same underlying property value?

Steve

http://www.mrclay.org/

Agreed. Some people may actually be using $parent as a variable name, not
difficult to imagine.

So far parent->foo seems to be the answer.

-Clint

My thoughts on the parent situations, as I'm not yet satisfied with the
current solution.

1. I tried to understand how the engine currently compiles and executes
   object property fetches. I found it to be incredibly complex and I
   certainly don't have the abilities to port this for statics. As such the
   "parent::$foo" syntax is dead unless someone else is going to do the
   necessary engine changes.

2. I think the "parent->foo" syntax is nice in concept, but I think that
   it's an absolute no-go as it doesn't fit in with the rest of PHP (and would
   still require some engine changes those complexity I can't really
   estimate). The parent->foo syntax is some off mix between parent::$foo
   (which makes sense) and $parent->foo (which also makes sense). parent->foo
   combines it in an odd way that doesn't look like PHP and adds yet another
   new syntax for something that's going to be a rare case anyway.

3. My suggestion is to avoid the engine and syntax related issues of parent
   property access by putting this as a function in the standard library
   instead. What I'm thinking about is a function like get_parent_property()
   which returns the ReflectionProperty for it. Then you could do something
   like this:

   public $foo {
   get { return 'parent is: ' .
   get_parent_property('foo')->getValue(); }
   set($val) { get_parent_property('foo')->setValue($val . '
   something'); }
   }

I know that this is not an optimal solution, but I would much prefer this
over some new syntax like "parent->foo". Once (if) static properties have
better engine support we can switch to the cleaner parent::$foo way. But
until then I think that this is a good compromise, especially considering
that accessing the parent property shouldn't be a very common operation, so
it's okay if it's a bit more verbose.

This is just a rough idea of what I'd do. The exact way this would work
still needs further discussion. E.g. one could make passing the property
name optional and assume the current property as default. Or one could not
return a ReflectionProperty and instead provide two functions
get_parent_property and set_parent_property (what about isset and unset in
that case though?)

So, what do you think about this?

Nikita