[RFC[ Property accessor hooks, take 2 View as Markdown

Le 21/02/2024 à 19:55, Larry Garfield a écrit :

Hello again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more polished property access hooks/interface properties RFC. It’s 99% unchanged from last summer; the PR is now essentially complete and more robust, and we were able to squish the last remaining edge cases.

Baring any major changes, we plan to bring this to a vote in mid-March.

https://wiki.php.net/rfc/property-hooks

It’s long, but that’s because we’re handling every edge case we could think of. Properties involve dealing with both references and inheritance, both of which have complex implications. We believe we’ve identified the most logical handling for all cases, though.

Note the FAQ question at the end, which explains some design choices.

There’s one outstanding question, which is slightly painful to ask: Originally, this RFC was called “property accessors,” which is the terminology used by most languages. During early development, when we had 4 accessors like Swift, we changed the name to “hooks” to better indicate that one was “hooking into” the property lifecycle. However, later refinement brought it back down to 2 operations, get and set. That makes the “hooks” name less applicable, and inconsistent with what other languages call it.

However, changing it back at this point would be a non-small amount of grunt work. There would be no functional changes from doing so, but it’s lots of renaming things both in the PR and the RFC. We are willing to do so if the consensus is that it would be beneficial, but want to ask before putting in the effort.

Yes please ! Pass !

I don't have voting rights, but we need this.

Cheers,

Pierre R.

I apologize if this has already been covered:

There are two shorthand notations supported, beyond the optional argument to set.
First, if a hook's body is a single expression, then the { } and return statement may be omitted and replaced with =>, just like with arrow functions.

Does => do any special auto-capturing of variables like arrow
functions or is it just a shorthand? Also, is this a meaningful
shorthand to the example a little further down:

public string $phone {
set = $this->sanitizePhone(...);
}

or do we always have to write it out?

public string $phone {
set => $field = $this->sanitizePhone($value);
}

Would PROPERTY be set inside sanitizePhone() as well?

You mention several ways values are displayed (whether or not they use
the get-hook), but what does the default implementation of
__debugInfo() look like now (or is that out of scope or a silly
question?)

For attributes, it would be nice to be able to target hooks
specifically with attributes instead of also all methods (e.g., a
Attribute::TARGET_GET_HOOK const). For example, if I were writing a
serialization library, I may want to specify #[UseRawValue] only on
getters to ensure that only the raw value is serialized instead of the
getter (which may be specific to the application logic, or
#[GetFromMethod] to tell the serialization library to get the value
from a completely different method. It wouldn't make sense to target
just any method with that attribute.

Hi

Once again in reading the proposal, the first thing I'm struck by are the
magic "$field" and "$value" variables inside accessors. The first time they
are used, they're used without explanation, and they're jarring.

[…]

Second: you don't have examples of defining BOTH get and set OTHER than
when using expressions for both accessors or a mix. I'm actually unclear
what the syntax is when both are defined. Is there supposed to be a ;
terminating each? Or a ,? Or just an empty line? Again, this is one of
the more common scenarios. It needs to be covered early, and clearly.

On a similar topic with regard to syntax and shorthands, I'd like to
quote myself from my previous year's email (Message-ID:
17d7983b-68b7-e273-a445-f8399c2510cc@bastelstu.be,
https://externals.io/message/120213#120216):

(5) I strongly dislike the doubly abbreviated form of public string $fullName => $this->first . " " . $this->last;. Having just the extra
'>' in there to distinguish it from a regular property feels non-obvious.

It's always possible to follow-up with syntax that allows for additional
brevity, the inverse is not true and I believe for such a semantically
complex feature, having clear and syntax syntax would be beneficial.

Best regards
Tim Düsterhus

After much on-again/off-again work, Ilija and I are back with a more polished property access hooks/interface properties RFC. It’s 99% unchanged from last summer; the PR is now essentially complete and more robust, and we were able to squish the last remaining edge cases.

Baring any major changes, we plan to bring this to a vote in mid-March.

https://wiki.php.net/rfc/property-hooks

It’s long, but that’s because we’re handling every edge case we could think of. Properties involve dealing with both references and inheritance, both of which have complex implications. We believe we’ve identified the most logical handling for all cases, though.

Once again in reading the proposal, the first thing I'm struck by are
the magic "$field" and "$value" variables inside accessors. The first
time they are used, they're used without explanation, and they're
jarring.

Additionally, once you start defining the behavior of accessors... you
don't start with the basics, but instead jump into some of the more
esoteric usage, which does nothing to help with the questions I have.

So, first:

• Start with the most basic, most expected usage for each of reading
  and writing properties.
• I need a better argument for why the $field and $value variables
  exist. Saying they're macros doesn't help those not deep into
  internals. As a user, why do they exist?

For $field, it's not a requirement. It's mostly for copy-paste convenience. A number of people have struggled on this point so if the consensus is to leave out $field and just use $this->propName directly, we can accept that. They can be re-added if reusable hook packages are added in the future (as noted in Future Scope).

For $value, it's to avoid boilerplate. For the majority case, you'll be just operating on an individual value trivially. Checking it's range, or uppercasing it, or whatever. Requiring the developer to provide a name explicitly is just extra work; it's much the same as how PHP doesn't require you to pass $this as the first argument to a method explicitly, the way Python and Rust do. It's just understood that $this exists, and once you learn that it's obvious.

On the occasions where you do want to specify an alternate name for some reason, or more likely you're providing a wider type, you can. But in the typical case it would just be one more thing for the dev to have to type out. This is especially true in what I expect to be a common case, which is promoted constructor arguments with an extra validator set hook on them.

It also introduces some ambiguity. If I specify only the name, does that mean I'm widening the type to mixed? Or just that I'm omitting the name? If specifying the name is rare, that's not really a big deal. If it's required in every case, it's a confusion point in every case.

In the interest of transparency. for comparison:

• Kotlin appears to require an argument name, but by convention recommends using "value".
• Swift makes it optional, with a default name of "newValue". (Same logic as in the RFC.)
• C# ... as far as I can tell, doesn't support a custom name at all; it's always called "value", implicitly.

Second: you don't have examples of defining BOTH get and set OTHER than
when using expressions for both accessors or a mix. I'm actually
unclear what the syntax is when both are defined. Is there supposed to
be a ; terminating each? Or a ,? Or just an empty line? Again,
this is one of the more common scenarios. It needs to be covered early,
and clearly.

... huh. I thought we had one in there somewhere. I will add one, thanks. Though to clarify, there's no separator character.

public string $foo {
get {
// ...
}
set {
// ...
}
}

Third: the caveats around usage with arrays... give me pause. While I'm
personally trying to not use arrays as much as possible, a lot of code
I see or contribute to still does, and the fact that an array property
that uses a write accessor doesn't allow the same level of access as a
normal array property is something I see leading to a lot of confusion
and errors. I don't have a solution, but I worry that this one thing
alone could be enough to prevent the passage of the RFC.

We completely agree that it's a suboptimal situation. But as explained, it is the way it is because it's not possible (as far as we can tell) to fully support hooks on array properties. If you can think of one, please share, because we'd love to make this part better. I don't like it either, but we haven't found a way around it. And that caveat doesn't seem like a good enough reason to not support hooks everywhere we actually can.

Fourth: the syntax around inheritance is not intuitive, as it does not
work in the same way as the rest of the language. I'm talking about
this:

public int $x {
    get: 2 * parent::$x::get()
}

Why do we need to use the accessors here? Why wouldn't it just be parent::$x?

Almost. Ilija spent some time looking into this, and it's possible with caveats.

First, there's then no way to differentiate between "access parent hook" and "read the static property $x on the parent". Arguably that's not a common case, but it is a point of confusion.

The larger issue is that parent::$x can't be just a stand-in for the backing value in all cases. While supporting that for the = operator is straightforward enough, it wouldn't give us access to ++, --, <=, and the dozen or so other operators that could conceivably apply. In theory those could all be implemented manually, but Ilija described that as "hundreds to thousands of lines of code" to do, which... is not time or code well spent. :-) Especially as this is a very edge-case situation to begin with. (In practice, I expect auto-generated ORM proxy code to be the primary user of accessing a parent property from a child hook. I can think of very few other cases where I'd want to use it.)

So we have the choice between making $a = parent::$prop and parent::$prop = $a work, but nothing else, inexplicably (creating confusion) or the slightly longer syntax that wouldn't support those other operations anyway so there's no confusion.

We feel the current approach is the better trade off, but if the consensus generally is for the shorter-but-inconsistent syntax, that can be changed.

I want to be clear: I really like the idea behind this feature, and
overall, I appreciate the design. From a user perspective, though, the
above are things that I found jarring as they vary quite a bit from our
current language design.

Note the FAQ question at the end, which explains some design choices.

There’s one outstanding question, which is slightly painful to ask: Originally, this RFC was called “property accessors,” which is the terminology used by most languages. During early development, when we had 4 accessors like Swift, we changed the name to “hooks” to better indicate that one was “hooking into” the property lifecycle. However, later refinement brought it back down to 2 operations, get and set. That makes the “hooks” name less applicable, and inconsistent with what other languages call it.

However, changing it back at this point would be a non-small amount of grunt work. There would be no functional changes from doing so, but it’s lots of renaming things both in the PR and the RFC. We are willing to do so if the consensus is that it would be beneficial, but want to ask before putting in the effort.

I personally would go with just "accessors".

This is a long, huge and comprehensive work, congratz to the authors.

It clearly shows that so much thought and work has been put into it
that it makes me cautious to even ask for further clarification.

Javascript have similar features via a different syntax, although that syntax would not be viable for PHP

Why not?

It feels quite a natural syntax for PHP and from someone oblivious to
the internal work, it appears to be a slight marginal change to the
existing RFC. Given the extensive work of this RFC, it seems pretty
obvious that this syntax will not work, I just don't know why.

I've added an FAQ section explaining why the Python/JS approach wouldn't really work. To be clear, Ilija and I spent 100+ hours doing research and design before we started implementation (back in mid-late 2022). We did seriously consider the JS-style syntax, but in the end we found it created more problems than it solves. For the type of language PHP is (explicit typed properties), doing it on the property itself is a much cleaner approach.

I apologize if this has already been covered:

There are two shorthand notations supported, beyond the optional argument to set.
First, if a hook's body is a single expression, then the { } and return statement may be omitted and replaced with =>, just like with arrow functions.

Does => do any special auto-capturing of variables like arrow
functions or is it just a shorthand?

No, there is nothing to capture. Inside the hook body you have $this the same as any other method.

Also, is this a meaningful
shorthand to the example a little further down:

public string $phone {
set = $this->sanitizePhone(...);
}

or do we always have to write it out?

public string $phone {
set => $field = $this->sanitizePhone($value);
}

Currently no, the set is always void; you have to write the value yourself. See the FAQ section on the topic for a detailed explanation.

However, I just had a long discussion with Ilija and there is one possibility we could consider: Use the return value only on the shorthand (arrow-function-like) syntax.

So you could do either of these, which would be equivalent:

set {
$this->phone = $this->santizePhone($value);
}

set => $this->santizePhone($value);

This would have the advantage of offering a return-to-set mechanism, as well as even shorter syntax in the simple case (and no question of $field vs $this->propName). But it would have the disadvantage of being potentially inconsistent between the short and long version. It also would mean the short version is incompatible with virtual properties; using a short-set would create a backing value, so it's non-virtual. But since "simple validation, maybe in a promoted constructor property" is likely to be one of the main use cases, it would simplify that case.

Not sure if that's a trade up or not. Thoughts from the list?

Would PROPERTY be set inside sanitizePhone() as well?

No. Like CLASS, it is materialized at compile time and has no meaning outside of its intended scope.

You mention several ways values are displayed (whether or not they use
the get-hook), but what does the default implementation of
__debugInfo() look like now (or is that out of scope or a silly
question?)

var_dump() shows the underlying backing value, bypassing get, since it's debugging the object state. If you implement __debugInfo(), that's a method like any other and you can do what you like, though you'll be reading through get hooks (just like using __serialize()).

For attributes, it would be nice to be able to target hooks
specifically with attributes instead of also all methods (e.g., a
Attribute::TARGET_GET_HOOK const). For example, if I were writing a
serialization library, I may want to specify #[UseRawValue] only on
getters to ensure that only the raw value is serialized instead of the
getter (which may be specific to the application logic, or
#[GetFromMethod] to tell the serialization library to get the value
from a completely different method. It wouldn't make sense to target
just any method with that attribute.

This feels very niche, honestly. Those would naturally have to be sub-cases of TARGET_METHOD anyway, so method-targeted attributes would need to be supported regardless. That makes hook-specific-targeting an easy and non-breaking add-on for a future RFC if it turns out to be useful in practice.

--Larry Garfield

A few things i was interested to get the idea around.
Was it thought about for the set{} for it to return the value to set the
property to
instead implicitly setting its own field?

eg

public string $name {
    set {
        return usfirst($value);
    }
}

Where the value returned in the set is what the property will be set to?

The answer to this question is best described on the RFC FAQ:
https://wiki.php.net/rfc/property-hooks#why_do_set_hooks_not_return_the_value_to_set

--
Marco Deleu

thank you for this proposal. there are some points i'd like to make
into this discussion:

• Thank you for the removal of $field, it was non-idomatic from a PHP POV.

• I would prefer that the short syntax $foo => null; be voted upon
  separately. Personally I think it could be confusing and is too close
  to a regular assignment for default value and I prefer not to have it
  and keep the rest of the RFC.

See my long reply to Rowan just now, where I go into this.

• The magic of detecting if a property is virtual or backed is - like
  Rowan said - subtle. I would also prefer this to be managed via an
  explicit mechanism, by for example keywording the property as
  "virtual", instead of the implicit way with the parsing based detection.

See my long reply to Rowan just now, where I go into this.

• As Doctrine project maintainer, we have had some troubles supporting
  read only properties for proxies. I would have hoped that with hooks I
  can overwrite a readonly property and "hook" into it instead by
  defining a getter, but "no setter". From my read of the RFC this would
  not be allowed and throws a compile time error. Could you maybe clarify
  why at least this special case is not possible? I didn't immediately
  get it from the RFC section on readonly as it only speaks about the
  problems in abstract.

Once again, readonly properties were designed sloppily without consideration of how they would interact with other features. Full asymmetric visibility would have been much better suited to what you describe, but that was rejected. (If hooks pass, we are considering taking a second attempt at aviz. Haven't decided yet.)

As for details, consider this technically legal (if ill-advised) code:

public DateTimeImmutable $now {
get {
return new DateTimeImmutable();
}
}

If that property is non-readonly, then while that may be weird, it's not really unexpected. There's no guarantee a property won't change value from one access to the next. UNLESS that property is readonly. But if it's readonly, what the heck does the above code do? It would be returning a different value on every request, so it violates one of the constraints on readonly. The hook can do arbitrary logic, which means there's really no way for the engine to detect at compile time "wait, you're doing something dynamic." (That would be an extreme amount of work unless PHP was pure-by-default, which it is not.)

For inheritance, this is the same reasoning for why a property cannot have the readonly marker removed in a child class. It breaks one of the expected constraints of the property, even if not the type per se. (So it's kinda a Liskov issue.)

This is true regardless of whether the property is virtual or not. Virtual properties just have the extra complication of "when you try to set it, there's an if (is_uninitialized()) check in the engine. What does that even mean when there's no backing property??"

There's one carve out that might be supportable, which is just a set hook on a readonly property. That MIGHT be able to work around readonly's flaws by making sure the set hook calls parent::$foo::set($value), to ensure the actual write happens in the parent (since readonly is private-set, not protected-set). Ilija tells me that could be tricky to do, however, so we'd rather punt on that for now. Follow-up RFCs (even this version) could flesh out that edge case alone without impacting the rest of the design.

--Larry Garfield

Hi Larry,

pt., 8 mar 2024 o 16:55 Larry Garfield larry@garfieldtech.com napisał(a):

Hi folks. Based on earlier discussions, we've made a number of changes to
the RFC that should address some of the concerns people raised. We also
had some very fruitful discussions off-list with several developers from
the Foundation, which led to what we feel are some solid improvements.

https://wiki.php.net/rfc/property-hooks

This RFC looks awesome, thanks Larry and Ilija I love the functionality in
its current shape.

Thank you everyone for the feedback so far, and if you still have some,

please say so. (Even if it's just to say that you're happy with the RFC
now so we feel more comfortable bringing it to a vote.)

The only thing I don't like and can still be worked on is the reflection
mechanism changes.
The proposed methods isVirtual and getRawValue, setRawValue pair introduces
a need to catch exceptions which could be eliminated by subtyping
ReflectionProperty.
Having these methods on a separate subtype allows returning a valid value.
I realize this isn't trivial because for the last 2 days, I was thinking
about giving it a name and TBH cannot figure out anything feasible.
If this is not possible to put in understandable words then at least
mention it in FAQ and why not.

Cheers,
Michał Marcin Brzuchalski

Hi folks. Based on earlier discussions, we've made a number of changes to the RFC that should address some of the concerns people raised. We also had some very fruitful discussions off-list with several developers from the Foundation, which led to what we feel are some solid improvements.

https://wiki.php.net/rfc/property-hooks

Smaller changes:

1. We've added a PropertyHookType enum for use in reflection, which lets us get rid of a possible exception.
2. get_mangled_object_vars()'s behavior is now defined to be the same as an array, ie, skip hooks.
3. A final property with a final hook is no longer an error. It's just silently redundant, like for methods.
4. Made explict what happens with recursive hook calls and method calls from a hook. The behavior here is the same as for __get/__set.
5. Made support for #[\Override] explicit.
6. Added an FAQ regarding the property-centric approach rather than method-centric approach.
7. Clarified that the parent::$foo::get() syntax works on a parent property regardless of whether it has hooks.
8. Clarified that untyped properties are supported. (Though, it's 2024, please don't use untyped properties.)
9. Clarified that interface properties cannot specify a wider write-type, for simplicity. That could be considered as a future add-on with no BC breaks.
10. Provided an explanation of how to interpret the parent-hook access syntax.
11. Added an FAQ item explaining why a 'virtual' keyword is not feasible.

Larger changes:

0. As noted a while ago, $field has been removed.

1. I've added an FAQ question regarding the parent::$foo::get() syntax, and why it is.

2. The $foo => expression shorthand has been removed. The legal shorthands are now:

public string $foo {
get => evaluates to a value;
set => assigns this value;
}

3. The set shorthand (with => ) now means "write this value instead". The non-shorthand version (set { } ) is always return void, so you have to assign the value yourself but you get more flexibility. Having updated the examples accordingly, I think this is actually a really nice and intuitive trade-off, as it makes the common transformation and validation cases (eg, in constructor promotion) even easier to follow with no redundancy.

4. On a set hook, the user may specify both a type and name, or neither. (That is, set {} or set (Foo $newFoo). If not specified, it defaults to the type of the property and $value, as before.

5. I restructured how the content in 2, 3, 4 is presented and moved some stuff around so that it flows more logically (I think).

6. The restrictions around references have been softened. Specifically, references are only disallowed if a backed property has a set hook. If it has only a get, or if it's a virtual property, references are allowed. We also added a future-scope section on a possible way to support assigning by reference in the future, if there is sufficient need.

7. Interfaces may now require a &get hook, or just 'get'. A class may use a &get hook on a 'get' interface declaration. This is the same logic as already exists for methods; we're just copying it.

Hopefully the above changes should resolve most outstanding concerns. I do think the updated shorthand handling is better overall, so I'm happy with it.

There also seems to be little consensus so far on naming this thing hooks vs accessors. Absent a consensus, we'll probably stick with hooks to avoid the effort of renaming all the things.

Thank you everyone for the feedback so far, and if you still have some, please say so. (Even if it's just to say that you're happy with the RFC now so we feel more comfortable bringing it to a vote.)

--Larry Garfield

Hi Larry

Thanks again for both of your work on this, I'm really hopeful this passes.

Was there ever any further discussion/resolution/decision about the use an explicit virtual keyword, and the related flag for creation of a backing store? I thought it was discussed by several people but I don't recall seeing any eventual consensus, and it looks to my eye that it hasn't changed from the original proposal: i.e. it's 'magic' and $this->{__PROPERTY__} won't work?

Is that correct?

Cheers

Stephen

Hi folks. Based on earlier discussions, we've made a number of changes
to the RFC that should address some of the concerns people raised. We
also had some very fruitful discussions off-list with several developers
from the Foundation, which led to what we feel are some solid
improvements.

https://wiki.php.net/rfc/property-hooks

Hi Larry,

Thanks again for the continuing hard work on this!

if a |get| hook for property |$foo| calls method |bar()|, then inside
that method |$this->foo| will refer to the raw property, both read and
write. If |bar()| is called from somewhere other than the hook, reading
from |$this->foo| will trigger the |get| hook. This behavior is
identical to that already used by |__get| and |__set| today.

I'm slightly confused by this.

If there is an actual property called $foo, then __get and __set will be
called only when it is out of visibility, regardless of the call stack -
e.g. a private property will always trigger __get from public scope, and
always access it directly from private scope: https://3v4l.org/R5Yos
That seems differ from what's proposed, where even a private call to
bar() would trigger the hook.

The protection against recursion appears to only be relevant for
completely undefined properties. For __get, the direct access can never
do anything useful - there's nothing to access: https://3v4l.org/2nDZS
For __set, it is at least possible for the non-recursive write to
succeed, but only in the niche case of creating a dynamic property:
https://3v4l.org/dpYOj I'm not sure that there's any equivalent to this
scenario for property hooks, since they can never be undefined/dynamic.

There is one exception to the above: if a property is virtual, then
there is no presumed connection between the get and set operations.
[...] For that reason, |&get| by reference is allowed for virtual
properties, regardless of whether or not there is a |set| hook.

I don't agree with this, and the example immediately following it
demonstrates the exact opposite: the &get and set hooks are both
proxying to the same backing value, and have all the same problems as if
the property was non-virtual. I would imagine a lot of real-life virtual
properties would be doing something similar: converting to/from a
different type, proxying to another object, etc.

I think this exception is unnecessarily complicated: either trust users
to handle the implications of combining &get with set, or forbid it.

Additionally, |&get| hooks are allowed for arrays as well, provided
there is no |set| hook.

I mentioned in a previous e-mail the possibility of using the &get hook
for array writes. Has this been considered?

That is:

$c->arr['beep'] = 'boop';

Would be equivalent to:

$temp =& $c->arr;
$temp['beep'] = 'boop';
unset($temp);

Which would be valid if $arr had an &get hook defined.

A |set| hook on a typed property must declare a parameter type that
is the same as or contravariant (wider) from the type of the property.

Once a property has both a |get| and |set| operation, however, it is
no longer covariant or contravariant for further extension.

How do these two rules interact?

Could this:

public string $foo {
   get => $this->_foo;
   set(string|Stringable $value) {
       $this->_foo = (string)$value;
   }
}

be over-ridden by this, where the property's "main type" remains
invariant but its "settable type" is contravariant?

public string $foo {
   get => $this->_foo;
   set(string|Stringable|SomethingElse $value) {
       $this->_foo = $value instanceof SomethingElse ?
$value->asString() : (string)$value;
   }
}

ReflectionProperty has several new methods to work with hooks.

There should be some way to reliably determine the "settable type" of a
property. At the moment, I think you would have to do something like this:

$setHook = $property->getHook(PropertyHookType::Set);
$writeType = $setHook === null ? $property->getType()
: $setHook->getParameters()[0]->getType();

Once again, I would like to make the case that asymmetric types are an
unnecessary complication that should be left to Future Scope.

The fact that none of the other languages referenced have such a feature
should also give us pause. There's nothing to stop us being the first to
innovate a feature, but we should be extra cautious when doing so, with
no previous experience to learn from. It also means there is no
expectation from users coming from other languages that this will be
possible.

If it genuinely seems useful, it can be added in a follow-up RFC, or
even a later version of PHP, with little impact on the rest of the
feature. But if we add it now and regret it, or some detail of its
implementation, we will be stuck with it forever.

Regards,

--
Rowan Tommins
[IMSoP]

Hi folks. Based on earlier discussions, we've made a number of
changes to the RFC that should address some of the concerns people
raised. We also had some very fruitful discussions off-list with
several developers from the Foundation, which led to what we feel are
some solid improvements.

https://wiki.php.net/rfc/property-hooks

Some comments and questions:

Be aware, the detection logic works on $this->[propertyName] directly at 
compile time, not on dynamic forms of it like $prop = 'beep'; 
$this->$prop. That will not trigger a backing value. 

How can that not cause issues?

 The set hook's return type is unspecified, and will silently be 
treated as void. 

What happens if you do specify a return type? Will it Error?

Implicit ''set'' parameter

If the write-type of a property is the same as its defined type 
(this is the common case), then the argument may be omitted 
entirely. 

…

If the parameter is not specified, it defaults to $value.

I am not a fan of this "magical" behaviour. Do we need this short cut,
and the following "Short-set"?

With asymmetric visibility that was previously proposed, the 
example can be further simplified. 

But it isn't here, so why is this example (and the next one) in the RFC?
:-)

Interaction with constructor property promotion

… In particular, the shorthand version of hook bodies and the 
ability to call out to private methods if they get complicated 
partially obviate the concern about syntactic complexity. 

Although that is true, it does add more complexity in tools that needs
to parse PHP, as there is now another piece of new syntax that needs to
be added (and tested with).

ReflectionProperty has several new methods to work with hooks.

getHooks(): array returns an array of \ReflectionMethod objects  
keyed by the hook they are for.

What will the name for the &get hook be? And shouldn't there be an enum
case for that as well?

cheers,
Derick

In regards to arrays, what about additional operations next to get/set?
I doubt this solution will cover all the use-cases or perhaps even
over-complicate things, just throwing the idea out there.

class Test {
    private array $_myData = [];
    public array $myData {
        get => $this->_myData;
        append => $this->_myData[] = $value;
    }
}

Thinking about the other post about offset and containers
(https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md):

class Test {
    private array $_myData = [];
    public array $myData {
        get => $this->_myData;
        append => $this->_myData[] = $value;
        write_dimension => $this->_myData[$offset] = $value;
    }
}

Those hooks may be possible; we'd have to try it and see. However, they also wouldn't be able to fully emulate arrays. $foo->bar['baz'][] = 'beep' could get very weird. Those wouldn't cover unsetting. Array functions like array_splice() still wouldn't work. Basically, there will never be a way to make arrays 100% transparent with hooks. That's why the RFC recommends still using a method for array modification, as that's already a very well-understood and flexible approach.

Fortunately, as currently written (append and write_dimension are forbidden), those additional hooks could be considered and added in their own RFC in the future with no BC break. Whether or not they make sense or cover "enough" use cases is a question that could be answered in the future, after Gina's RFC passes.

So on this one, I think "punt" is the best option for now. It can be safely revisited in the future.

Is this issue restricted to arrays only? From my understanding objects
functioning as arrays are already by reference and thus should not
suffer from this?

class Test {
    private ArrayObject $_myData;
    public ArrayObject $myData {
        get => $this->_myData;
    }

    public function __construct() {
        $this->_myData = new ArrayObject();
    }
}

// would this work without issues?
$obj = new Test();
$obj->myData[] = 'test';

Mostly correct. Objects pass by handle, not by reference. (You can pass an object by reference instead, and it behaves subtly differently.) But the net effect is the same. Your sample code there would run fine.

--Larry Garfield

Hi, thanks for the RFC and the effort put into trying to make it
palatable to skeptical minds!

After reading most of the discussion in this thread I believe that the
RFC in its current form can work and that I will get used to it's
"peculiarities", but an idea occurred to me that may have some
advantages, so here goes:

Use the "set" keyword that you've already introduced to set the raw
value of a "backed" property:

public int $name {
set {
set strtoupper($value);
}
}
Or when used in short form:

public int $name {
set => set strtoupper($value);
}

Advantages in no particular order:

1. Shorter than $this->name
2. No magic $field
3. Short and long form works the same

Disadvantage: "Set" can only be used to set the raw value inside the
hook method itself. Or maybe that's a good thing too. To be honest, I
don't love that $this->name sometimes goes through the hook and
sometimes not. I'd prefer if the raw value could only be accessed
inside the hooks or via a special syntax like f.ex. $this->name:raw

If there are any use cases or technical details that I've missed that
would make this syntax unfavourable, I apologize.

Interesting idea. Not being able to write the raw value except in the set hook isn't a bug, but an important feature, so that's not a downside. (Modulo reflection, which is a reasonable back-door.)

However, there's a few other disadvantages that probably make it not worth it.

1. set is not actually a keyword at the moment. It's contextually parsed in the lexer, so it doesn't preclude using set as a constant or function name the way a full keyword does. (PHP has many of these context-only keywords.) Making it a keyword inside the body of the hook would do that, however.
2. Like $field, it would be a syntax you just "have to know". Most people seem to hate that idea, right or wrong.
3. Like the considered syntaxes for parent-access, it wouldn't be possible to do anything but a direct write. So set => set++ wouldn't be possible, whereas with $this->prop all existing operations should "just work."
4. Would we then also want a get keyword in the get hook to be parallel? What does that even do there? It would have the same implications as point 3 in get, so we're back to $field by a different spelling.

So it's an interesting concept, but the knock-on effects would lead to a lot more complications.

Another observation (I apologize for being late to the game but it was
a long RFC and thread to read through):

What would happen if we stopped talking about virtual vs. backed
properties? Couldn't we just treat a property that was never set the
same as any other uninitialized property?
What I mean is, that if you try to access the raw value of a property
with a set hook that never sets its own raw value, you'd get either
null or Typed property [...] must not be accessed before
initialization, just like you'd expect if you're already used to modern
php. Of course you'd just write your code correctly so that that never
happens. It's already the case that uninitialized properties are
omitted when serializing the object so there would be no difference
there either.

The advantage here would be that there's no need to detect the virtual
or backed nature of the property at compile time and the RFC would be a
lot shorter.

Unfortunately the backed-vs-virtual distinction is quite important at an implementation level for a few reasons.

1. A backed property reserves memory space for that property. A virtual property does not. Making virtual properties "unused backed" properties would increase memory usage for values that would never be usable.
2. There would be no realistic way to differentiate between a get-only virtual property with no storage, and a backed property that just happens to have a get hook but no set hook. Meaning you would be able to write to an otherwise-inaccessible backing value of the property.
3. That would then appear in serialization, even though it's impossible to get to from code without using reflection. Which is just all kinds of confusing.

So for practical reasons, the distinction isn't just a user-facing difference but an important engine-level distinction we cannot avoid.

Cheers.

--Larry Garfield

[Including my full previous reply, since the list and gmail currently
aren't being friends. Apologies that this leads to rather a lot of
reading in one go...]

Eh, I'd prefer a few big emails that come in slowly to lots of little emails that come in fast. :-)

Hello again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more polished property access hooks/interface properties RFC.

Hello, and a huge thanks to both you and Ilija for the continued work
on this. I'd really like to see this feature make it into PHP, and
agree with a lot of the RFC.

My main concern is the proliferation of things that look the same but
act differently, and things that look different but act the same:

snip

• a and b are both what we might call "traditional" properties, and
  equivalent to each other; a uses legacy syntax which we haven't
  removed for some reason

I don't know why we haven't removed var either. I can't recall the last time I saw it in real code. But that's out of scope here.

snip

I think there's some really great functionality in the RFC, and would
love for it to succeed in some form, but I think it would benefit from
removing some of the "magic".

Regards,

--
Rowan Tommins
[IMSoP]

I'm going to try and respond to a couple of different points together here, including from later in the thread, as it's just easier.

== Re, design philosophy:

In C#, all "properties" are virtual - as soon as you have any
non-default "get", "set" or "init" definition, it's up to you to declare
a separate "field" to store the value in. Swift's "computed properties"
are similar: if you have a custom getter or setter, there is no backing
store; to add behaviour to a "stored property", you use the separate
"property observer" hooks.

Kotlin's approach is philosophically the opposite: there are no fields,
only properties, but properties can access a hidden "backing field" via
the special keyword "field". Importantly, omitting the setter doesn't
make the property read-only, it implies set(value) { field = value }

A little history here to help clarify how we ended up where we are: The original RFC as we designed it modeled very closely on Swift, with 4 hooks. Using get/set at all would create a virtual property and you were on your own, while the beforeSet/afterSet hooks would not. We ran that design by some PHP Foundation sponsors a year ago (I don't actually know who, Roman did it for us), and the general feedback was "we like the idea, but woof this is complicated with all these hooks and having to make my own backing property for all these little things. Couldn't this be simplified?" We thought a bit more, and I off-handedly suggested to Ilija "I mean, would it be possible to just detect if a get/set hook is using a backing store and make it automatically? Then we could get rid of the before/after hooks." He gave it a quick try and found that was straightforward, so we pivoted to that simplified version. We then realized that we had... mostly just recreated Kotlin's design, so shrugged happily and went on with life.

As noted in an earlier email, C#, Kotlin, and Swift all have different stances on the variable name for the incoming value. We originally modeled on Swift so had that model (optional newVal name), and also because we liked how compact it was. When we switched to the simplified, incidentally Kotlin-esque approach, we just kept the optional variable as it works.

I think where that ended up is pretty nice, personally, even if it is not a direct map of any particular other language.

== Re asymmetric typing:

This is capability already present today if using a setter method.

class Person {
private $name;

public function setName(UnicodeString|string $name)
{
$this->name = $value instanceof UnicodeString ? $value : new UnicodeString($value);
}
}

And widening the parameter type in a child class is also entirely legal. As the goal of the RFC is, essentially, "make most common getter/setter patterns easy to add to a property without making an API-breaking method, so people don't have to add redundant just-in-case getters and setters all the time," covering an easy-to-cover use case seems like a good thing to do.

It also ties into the question of the explict/implicit name, for the reason you mentioned earlier (unspecified means mixed), not by intent. More on that in another section.

== Re virtual properties:

Ilija and I talked this through, and there's pros and cons to a virtual keyword. Ilija also suggested a backed keyword, which forces a backed property to exist even if it's not used in the hook itself.

• Adding virtual adds more work for the developer, but more clarity. It would also mean $this->$propName or $this->{PROPERTY} would work "as expected", since there's no auto-detection for virtual-ness. On the downside, if you have a could-be-virtual property but never actually use the backing value, you have an extra backing value hanging around in memory that is inaccessible normally, but will still show up in some serialization formats, which could be unexpected. If you omit one of the hooks and forget to mark it virtual, you'll still get the default of the other operation, which could be unexpected. (Mostly this would be for a virtual-get that accidentally has a default setter because you forgot to mark it virtual.)
• Doing autodetection as now, but with an added "make a backing value anyway" flag would resolve the use case of "My set hook just calls a method, and that method sets the property, but since the hook doesn't mention the property it doesn't get created" problem. It would also allow for $this->$propName to work if a property is explicitly backed. On the flipside, it's one more thing to think about, and the above example it solves would be trivially solved by having the method just return the value to set and letting the set hook do the actual write, which is arguably better and more reliable code anyway.
• The status quo (auto-detection based on the presence of $this->propName). This has the advantage it "just works" in the 95% case, without having to think about anything extra. The downside is it does have some odd edge cases, like needing $this->propName to be explicitly used.

I don't think any is an obvious winner. My personal preference would be for status quo (auto-detect) or explicit-virtual always. I could probably live with either, though I think I'd personally favor status quo. Thoughts from others?

I agree that a flag to make the field virtual (thus disabling the backing store) makes more sense than a flag to make it backed; It's also easier to understand when comparing hooked properties with regular properties (essentially, backed is the default, you have to opt-in to it being virtual). I don't think the edge cases of "auto" make it worthwhile just to not need "virtual".

== Re reference-get

Allowing backed properties to have a reference return creates a situation where any writes would then bypass the set hook, and thus any validation implemented there. That is, it makes the validation unreliable. A major footgun. The question is, do we favor caveat-emptor flexibility or correct-by-construction safety? Personally I always lead toward the latter, though PHP in general is... schizophrenic about it, I'd say. :-)

At this point, we'd much rather leave it blocked to avoid the issue; it's easier to enable that loophole in the future if we really want it than to get rid of it if it turns out to have been a bad idea.

There is one edge case that might make sense: If there is no set hook defined, then there's no set hook to worry about bypassing. So it may be safe to allow &get on backed properties IFF there is no set hook. I worry that is "one more quirky edge case", though, so as above it may be better to skip for now as it's easier to add later than remove. But if the consensus is to do that, we're open to it. (Question for everyone.)

I don't have strong feeling about this, but in general I usually tend to prefer options that are consistent, and give power/options to the developer. If references are opt-in anyway, I see that as accepting the trade-offs. If a developer doesn't want to allow by-ref modifications of the property, why would they make it referenceable in the first place? This sounds a bit like disallowing regular public properties because they might be modified outside the class - that's kind of the point, surely.

== Re

== Re arrays

Regarding arrays, have you considered allowing array-index writes if
an &get hook is defined? i.e. "$x->foo['bar'] = 42;" could be treated
as semantically equivalent to "$_temp =& $x->foo; $_temp['bar'] = 42;
unset($_temp);"

That's already discussed in the RFC:

The simplest approach would be to copy the array, modify it accordingly, and pass it to set hook. This would have a large and obscure performance penalty, and a set implementation would have no way of knowing which values had changed, leading to, for instance, code needing to revalidate all elements even if only one has changed.

Unless we were OK with that bypassing the set hook entirely if defined, which, as noted above, means any safety guarantees provided by a set hook are bypassed, leading to untrustworthy code.

== Re hook shorthands and return values

Ilija and I have been discussing this for a bit, and we've both budged a little. :-) Here's our counter-proposal:

• Drop the "top level" shorthand, for get-only hooks.
• Keep the => shorthand for the get hook itself.
• For a set hook, the {} form has no return value; set the value yourself however you want.
• For a set hook, the => form implies a backed value and will set the property to whatever value that evaluates to.

So these are equivalent:

public $foo { set { $this->foo = $value; } }
public $foo { set => $value; }

These are equivalent:

public string $foo {
get {
return strtoupper($this->foo);
}
}
public string $foo { get => strtoupper($this->foo); }

And this goes away:

public string $foo => strtoupper($this->foo);

That covers the common cases with an arrow-function-like syntax that behaves as you'd expect (it returns things), and allows a longer version with arbitrarily complex logic if desired. It also means that each syntax variant does mean something importantly different.

Would that be an acceptable compromise? (Question for everyone.)

I think the examples given are clear, and the lack of the top-level short closure-esque version makes it more obvious. Forgive me, I must have missed some of the previous comments - is there a reason the 'full' setter can't return a value, for the sake of consistency? I understand that you don't want "return to set" to be the only option, for the sake of e.g. change/audit logging type functionality (i.e. set and then some action to record that the change was made), but it seems a little odd and inconsistent to me that the return value of a short closure would be used when the return value of the long version isn't. This isn't really a major issue, I'm just curious if there was some explanation about it?

== Re the $value variable in set

Honestly, Rowan's earlier point here is the strongest argument in favor for me of the current RFC approach. Anywhere else in PHP, something that looks like a parameter and has no type, like ($param), means its type is mixed. It would be weird and confusing to be different here. That's above and beyond the issue of forcing people to retype something obvious every time. (I cite again, recent PHP's trend toward removing needless boilerplate, which is very good.) Requiring that the type be specified, for consistency, makes little sense if the type is not allowed to vary. You're just repeating a string from earlier on the same line, for no particular benefit.

I genuinely don't understand the pushback on $value. It's something you learn once and never have to think about again. It's consistent.

Ilija jokingly suggested making it always $value, unconditionally, and allowing only the type to be specified if widening:

public int $foo { set(int|float) => floor($value); }

Though I suspect that won't go over well, either. :-)

So what makes the most sense to me is to keep $value optional, but IF you specify an alternate name, you must also specify a type (which may be wider). So these are equivalent:

public int $foo { set (int $value) => $value + 1 }
public int $foo { set => $value + 1 }

And only those forms are legal. But you could also do this, if the situation called for it:

public int $foo { set(int|float $num) => floor($num) + 1; }

This "all or nothing" approach seems like it strikes the best balance, gives the most flexibility where needed while still having the least redundancy when not needed, and when a name/type is provided, its behavior is the same as for a method being inherited.

Does that sound acceptable? (Again, question for everyone.)

My only question with this is the same as I had in an earlier reply (and I'm not sure it was ever answered directly?), and you allude to this yourself: everywhere else, ($var) means a parameter with type mixed. Why is the type required here, when you've specifically said you want to avoid boilerplate? If we're going to assume people can understand that (implicit property-type $value) is implicit, surely we can also assume that they will understand "specifying a parameter without a type" means the parameter has no type (i.e. is mixed`).

Again, for myself I'd be likely to type it (or regular parameters, properties, etc) as mixed if that's what I want anyway, but the inconsistency here seems odd, unless there's some until-now unknown drive to deprecate type-less parameters/properties/etc.

The alternative that gives the most future-flexibility is to do neither: The variable is called $value, period, you can't change it, and you can't change the type, either. There is no () after set, ever. Punt both of those to a later follow-up. I'd prefer to include both now, but including neither now is the next-safer option.

Regarding $field

Sigh, now y'all like it. :-P Most of the feedback on this has been negative, so I'm inclined to leave it out at this point, unless there's a major swing in feedback to bring it back. But the RFC seems more likely to pass without it than with right now.

--Larry Garfield

Cheers

Stephen

I genuinely don't understand the pushback on $value. It's something you learn once and never have to think about again. It's consistent.

Ilija jokingly suggested making it always $value, unconditionally, and allowing only the type to be specified if widening:

public int $foo { set(int|float) => floor($value); }

Though I suspect that won't go over well, either. :-)

Same, I don't understand the pushback on $value, for me this seems clearer and less confusing than the existing $this variable when I was first learning about OOP.
And I would be in favour of just making it always $value, if people feel that strongly about being able to name it with a custom name they could propose this as a follow-up RFC.

One thing the RFC should note, which I would expect to be the same as the array cast, is how do backed/virtual properties interact with get_mangled_object_vars()

Best regards,

Gina P. Banyard

A little history here to help clarify how we ended up where we are: The original RFC as we designed it modeled very closely on Swift, with 4 hooks. Using get/set at all would create a virtual property and you were on your own, while the beforeSet/afterSet hooks would not.

This is interesting to hear, because the current RFC comes across - or at least did to me, on first reading - as "these are normal properties, and then you're adding some magic on top of them".

The Eureka! moment for me was realising that the whole thing makes more sense if you start with "virtual" properties, and then add some magic to avoid declaring a second property to store a backing value.

This "virtual-first" view is how my current thinking is framed, which I tried to demonstrate here: https://wiki.php.net/rfc/property-hooks/imsop-suggestion

== Re asymmetric typing:

This is capability already present today if using a setter method.

class Person {
private $name;

public function setName(UnicodeString|string $name)
{
    $this->name  =  $value  instanceof UnicodeString ? $value : new  UnicodeString($value);         
}

}

I find this unconvincing. Just because this method name starts with "set", doesn't mean everything it does should be possible in a property setter.

You could also have a method that took two arguments:

public function setName(string $first, string $last)
{
$this->name = $first . ' ' . $last;
}

Or a mandatory argument and an optional flag:

public function setName(string $name, bool $normalise=false)
{
$this->name = $normalise ? ucwords($name) : $name;
}

Neither of those are going to be translatable to property set hooks, and that's totally fine.

covering an easy-to-cover use case seems like a good thing to do.

This is the crux: I don't think asymmetric types are easy.

Firstly, they mean that every single piece of static analysis or reflection which wants to ask "what is the type of this property" has to take into account the new concept that the "settable type" might be different from the "gettable type".

Secondly, they mean that a user has to understand that this code might result in the variable magically changing type:

$me = 'Rowan';
$object->name = $me;
$me = $object->name;
// $me is now magically an object!
// how do I get my string back?

Thirdly, there's a simpler alternative, providing a separate virtual property, which can then be readable as well as writeable:

$me = 'Rowan';
$object->nameString = $me;
$me = $object->nameUnicode;
// easily visible that we're reading a different property, with a different type
$object->nameUnicode = $me;
$me = $object->nameString;
// fully reversible, and no need to know how the object implements it

It also ties into the question of the explict/implicit name, for the reason you mentioned earlier (unspecified means mixed)

Another reason to dislike it as complicating the proposal, IMHO.

== Re virtual properties:

On the downside, if you have a could-be-virtual property but never actually use the backing value, you have an extra backing value hanging around in memory that is inaccessible normally, but will still show up in some serialization formats, which could be unexpected.

This is a reasonable argument in favour of automatic detection.

If you omit one of the hooks and forget to mark it virtual, you'll still get the default of the other operation

My immediate question here is "why?" Why does the set hook magically come into existence, just because you defined the get hook a particular way?

Consider this example, using a virtual property:

private int $_nextId;
public int $nextId {
get { $this->_nextId ??= 0; return $this->_nextId++; }
}

This might not be the most common thing to do, but (as far as I know) it will work. There is no direct write access to the property, but we need somewhere to store the incrementing value.

Then we say "woof this is complicated having to make my own backing property for all these little things; can this be simplified?" and write this:

public int $nextId {
get { $this->nextId ??= 0; return $this->nextId++; }
}

Great! We've got rid of the explicit backing field, and the code still works... but wait! Suddenly, a setter has appeared, even though we never asked for one!

I suppose the reasoning is that it's quite common to want to implement the default version of one or other hook; but note that with the currently proposed short-hand the defaults can be written as:

get => $this->someName;
set($value) => $value;

If that's still too long, we can borrow from C#, where they can be written as:

get;
set;

That gives the choice of whether the default is implemented back to the user, and removes a foot-gun inconsistency between virtual and backed properties.

• Doing autodetection as now, but with an added "make a backing value anyway" flag would resolve the use case of "My set hook just calls a method, and that method sets the property, but since the hook doesn't mention the property it doesn't get created" problem.

Unless I'm missing something, no it wouldn't. There's still no way for a method to refer to that backing value. If the method sets the property, it will just end up recursively calling the set hook. The backing value remains visible only inside the hooks.

Unless I've misunderstood, and the implementation somehow chooses the meaning of $this->foo based on whether the set hook is somewhere in the call stack, in which case ... yikes!

== Re reference-get

Allowing backed properties to have a reference return creates a situation where any writes would then bypass the set hook, and thus any validation implemented there.

As Stephen Reay says, isn't that up to the user to decide?

Again, the backed property isn't doing anything that a virtual property plus an explicit backing property couldn't:

private string _$foo;
public string $foo {
&get { return $this->_foo; }
set { /* whatever */ }
}

Either we're willing to trust the user with that power, and should let them do the same thing with a magic backing field; or we're not willing to trust them, and should not allow &get at all.

There is one edge case that might make sense: If there is no set hook defined, then there's no set hook to worry about bypassing. So it may be safe to allow &get on backed properties IFF there is no set hook.

Given my above argument that the set hook should never be added automatically / implicitly, this could be simplified to "allow an &get hook only if no other hook is defined" (i.e. you can't have both "get" and "&get", and you can't have both "&get" and "set").

== Re arrays

The simplest approach would be to copy the array, modify it accordingly, and pass it to set hook.

This isn't what I was suggesting.

I was suggesting that modifying the array called the &get hook, and modified whatever array that returned.

Unless we were OK with that bypassing the set hook entirely if defined, which, as noted above, means any safety guarantees provided by a set hook are bypassed, leading to untrustworthy code.

Again, already possible as soon as you have any &get hooks at all:

$temp =& $foo->bar;
$temp[42] = true;
var_dump($foo->bar);

== Re hook shorthands and return values

Ilija and I have been discussing this for a bit, and we've both budged a little. :-) Here's our counter-proposal:

• Drop the "top level" shorthand, for get-only hooks.
• Keep the => shorthand for the get hook itself.
• For a set hook, the {} form has no return value; set the value yourself however you want.
• For a set hook, the => form implies a backed value and will set the property to whatever value that evaluates to.

I'm 100% behind this.

I genuinely don't understand the pushback on $value. It's something you learn once and never have to think about again. It's consistent.

For me, the problem is in having both a special name and the ability to choose the name. There's nowhere else in the language where that happens.

I also can't think of any reason someone would choose a name other than $value. I can well imagine coding standards mandating that it always be called that, making it boring boilerplate.

Ilija jokingly suggested making it always $value, unconditionally, and allowing only the type to be specified if widening:

public int $foo { set(int|float) => floor($value); }

Honestly, if you think asymmetric types are a good idea (which I don't), that makes a lot more sense.

Specifying the writeable type has nothing to do with the name of the value, it's a special case that will be rarely used, and should draw attention to its key feature: the type.

The alternative that gives the most future-flexibility is to do neither: The variable is called $value, period, you can't change it, and you can't change the type, either. There is no () after set, ever. Punt both of those to a later follow-up. I'd prefer to include both now, but including neither now is the next-safer option.

This is by far my preferred option. Asymmetric types are too much magic, and choosing the variable name is just one more case to consider.

Regarding $field

Sigh, now y'all like it. :-P

As I said at the top, the Eureka! moment for me was thinking "virtual first".

In the original RFC, it was implied (or, it seemed to me) that $field was just an alias for referencing the "real" property. That's a really tempting interpretation, but it's not what's happening.

What's really happening is that the property itself is virtual: every single access to it goes through the hooks. But, within the hooks, we have provided a magic variable, stored on the object but accessible only there, where the hooks can store a value of the same type as the virtual property.

Once I came to that interpretation, it became much more intuitive to call that magic variable by a magic name like $field; than to re-use the syntax that would normally refer to the property, and make it sometimes reference this new thing instead.

To re-iterate an earlier point, though, I think the language should choose. There should be exactly one way to refer to the backing field, whether that's $this->foo, $field, or get_backing_field(). Don't leave users reading each other's code and not being sure if it's doing the same thing.

Regards,

Rowan Tommins
[IMSoP]