Hi Rowan,
Thanks for clearing up that the return value will be ignored. I
understand better why that is (void = null). I do like the updated RFC
better than the one with the $field variable to write to. My yield
suggestion was an idea derived from that earlier $field write proposal,
but I wanted to share it anyhow.
I do note that $this->propName might suggest that the backing value is
accessible from other locations than only the property's own get/set
methods, because of $this usage. I would rather have a $field in get
referring to the current value, and a $value in set referring to the
passed value. So with the full name example:
public string $fullName {
get ($field): string => $field;
set ($value): string {
[$this->first, $this->last] = explode(' ', $value);
return $value;
}
}
I think it would make absolutely clear that the backing value is only
accessible in the local get/set scope. Regarding returning void=null,
this is something that IDE and static analyzers already pick-up as an
error. I think being stricter on that in this RFC would actually make
sense, and treat void not as null. So with a slightly different full
name example:
public string $fullName {
get ($field): string => $this->first . ' ' . $this->last;
set ($value): void {
[$this->first, $this->last] = explode(' ', $value); // real
void, no value returned
}
}
And why yield is magic, I do not get that. The word and the expression
actually expresses that something is, well, yielded. yield is a word
that is reserved in the language that serves the purpose of the problem.
I would use it. It is even explainable that the set function is treated
as a generator function.
Regards,
Frederik
On 26-02-2024 20:39, Rowan Tommins [IMSoP] wrote:
On 26/02/2024 19:02, Frederik Bosch wrote:
That's how it always has been, no? So in your example, short code
abbreviated form would not work. One has to write a block.
public string$fullName { set=> [$this->first,
$this->last] = explode <http://www.php.net/explode>(' ', \ucfirst
<http://www.php.net/ucfirst>($value)); // error, $fullName is a
string, returning array
}
public string$fullName { set{
[$this->first, $this->last] = explode
<http://www.php.net/explode>(' ', \ucfirst
<http://www.php.net/ucfirst>($value)); // no error, not returning
}
}
I think the intention is that both the block and the arrow syntax
would have any return value ignored, as happens with constructors, for
example. Note that in PHP, there is actually no such thing as "a
function not returning a value", even a "void" function actually
returns null; so if the return value was treated as meaningful, your
second example would give an error "cannot assign null to property of
type string".
However, as noted in a previous message, I agree that the short form
meaning "the value returned is saved to the backing field" is both
more expected and more useful.
The "yield" idea is ... interesting. I think personally I find it a
bit too magic, and too cryptic to be more readable than an explicit
assignment. Opinions may vary, though.
Regards,
--
Frederik Bosch
Partner
Genkgo logo
Mail: f.bo...@genkgo.nl <mailto:f.bo...@genkgo.nl>
Web: support.genkgo.com <https://support.genkgo.com>
Entrada 123
Amsterdam
+31 20 244 1920
Genkgo B.V. staat geregistreerd bij de Kamer van Koophandel onder nummer
56501153
