undefined | Better HN

0 pointsidoubtit1y ago0 comments

> hopefully hooks will be super short and this won't be a major issue.

Even if a PHP project has a policy of short hooks, I think hooks impede clarity.

    public string $countryCode
    {
        set (string $countryCode) {
            $this->countryCode = strtoupper($countryCode);
            $this->country = nameCountry($this->countryCode);
        }
        get => ...

In this short hook, the first line of the setter obviously uses the underlying property. But the second line of the setter...

Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?

Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?

If not, is there a way to call the `countryCode` getter from this setter?

If quickly parsed the doc and the RFC, so I don't have answers (I suppose it's yes, no, no). But even if I knew how this code behaved, I would still think it's much more complex than plain methods.

public string $countryCode { set (string $countryCode) { $this->countryCode = strtoupper($countryCode); $this->country = nameCountry($this->countryCode); } get => ...

0 comments

5 comments · 2 top-level

chx1y ago· 3 in thread

> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)?

To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry

> Does reading `$this->countryCode` use the getter hook, even it's from a `countryCode` hook?

same

> If not, is there a way to call the `countryCode` getter from this setter?

There is although it's a bit tricky and not intuitive but I feel this falls under the "it is enough this is possible, there's no need for it to be easy": "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." Using dynamic properties in what should be simple code should be rare enough this is not a problem. It's like a bridge convention, the benefits vastly outweigh the drawbacks.

c0wb0yc0d3r1y ago

> Does `$this->country =` use the setter even if it's in a hook (but not a `country` hook)? To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry

I would expect hooks for properties other than `$this->contryCode` to be called inside of a `$this->contryCode` hook.

Btw the docs that are linked in the post[0] seem to be clearer than the example in the announcement. Reads less ambiguously to me.

[0]: https://www.php.net/manual/en/migration84.new-features.php#m...

alt2271y ago

You are corect that the docs read much clearer. Why would they muddy the concept in the release post?

patates1y ago

> To me it is obvious hooks won't use other hooks because that could lead to an infinite loop in a hurry

Yet in Javascript:

test = { set a(x) { this.b = x }, get a() { return 2 }, set b(x) { this.c = 10 }}

Object { a: Getter & Setter, b: Setter }

test.a = 10

test

Object { a: Getter & Setter, b: Setter, c: 10 }

and yes it's possible to make infinite loops.

Gabrys11y ago

Why would you write such code though? If you want to store an underlying properly, use a differently named (and private) one:

public string $countryCode { set (string $countryCode) { $this->_countryCode = strtoupper($countryCode); $this->country = nameCountry($this->_countryCode); }

j / k navigate · click thread line to collapse