Re: Re: [RFC] Polling API
| From: | Jakub Zelenka | Date: | Sat, 25 Apr 2026 22:04:33 +0000 |
| Subject: | Re: Re: [RFC] Polling API | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130696@lists.php.net to get a copy of this message | ||
On Thu, Apr 2, 2026 at 10:15 PM Tim Düsterhus <tim@bastelstu.be> wrote:
> Hi
>
> Am 2026-03-31 15:23, schrieb Jakub Zelenka:
> > There is actually no internal API for hooks so it would require using
> > object handlers (which is from the user space point of view just
> > __get). It
> > means no stubs declaration either. We also don't have an internal
> > policy
> > where to use hooks and where methods. So there are still lots of
> > blockers
> > to start using it in core.
>
> While I agree with the conclusion that using hooks internally is
> complicated and there is no real policy there, Valentin was actually
> making a good point: We could use regular
readonly properties
> for
> those cases where we're just exposing a “constructor parameter”.
> Specifically:
>
> - Context::getBackend() -> public readonly Backend $backend;
> - Watcher::getHandle() -> public readonly Handle $handle;
>
> Potentially Watcher::$data could also be a regular (non-readonly)
> property, or does modifyData() contain additional logic that is
> not
> just “store the value somewhere”?
>
I tried to convert few but it resulted in quite ugly inconsistent mess.
Some of those need back calls to backend so they are really not ideal for
this. So I will stick with the current getters as the API is a bit nicer
with them IMO.
Kind regards,
Jakub