Hi internals,
Ilija and I would like to start a discussion about the following RFC:
https://wiki.php.net/rfc/pass_scope_to_magic_accessors
When using magic methods to access actual properties, respecting their
declared visibility is often desired. Yet, accessing the calling scope to
emulate the visibility restrictions is unreasonably difficult at the
moment. This RFC proposes to pass the calling scope to magic accessors to
make it trivial to get it.
Kind regards,
Nicolas
Hi
Ilija and I would like to start a discussion about the following RFC:
https://wiki.php.net/rfc/pass_scope_to_magic_accessorsWhen using magic methods to access actual properties, respecting their
declared visibility is often desired. Yet, accessing the calling scope to
emulate the visibility restrictions is unreasonably difficult at the
moment. This RFC proposes to pass the calling scope to magic accessors to
make it trivial to get it.
Unless I missed anything, the RFC does not explain how the values that
are passed into the second parameter will look like. What kinds of
strings will be passed? When will the value be null?
Best regards
Tim Düsterhus
Hi internals,
Ilija and I would like to start a discussion about the following RFC:
https://wiki.php.net/rfc/pass_scope_to_magic_accessorsWhen using magic methods to access actual properties, respecting their
declared visibility is often desired. Yet, accessing the calling scope to
emulate the visibility restrictions is unreasonably difficult at the
moment. This RFC proposes to pass the calling scope to magic accessors to
make it trivial to get it.
Why not a new function, e.g. func_call_scope()? It could work
everywhere, not only in magic methods.
I guess it would be tricky with calls to the parent magic method when
you need the "outer calling scope", but I'd like to see some reasoning
in the RFC.
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Not just that, but debug_backtrace() already exists for that purpose.
Hi internals,
Ilija and I would like to start a discussion about the following RFC:
https://wiki.php.net/rfc/pass_scope_to_magic_accessorsWhen using magic methods to access actual properties, respecting their
declared visibility is often desired. Yet, accessing the calling scope to
emulate the visibility restrictions is unreasonably difficult at the
moment. This RFC proposes to pass the calling scope to magic accessors to
make it trivial to get it.Why not a new function, e.g. func_call_scope()? It could work
everywhere, not only in magic methods.I guess it would be tricky with calls to the parent magic method when
you need the "outer calling scope", but I'd like to see some reasoning
in the RFC.--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
--
To unsubscribe, visit: https://www.php.net/unsub.php
Not just that, but
debug_backtrace()already exists for that purpose.
I have use debug_backtrace() exactly for this purpose in the past. It
was to make a protected property readable/writable, but only by certain
"friend classes."
It's pretty trivial to make happen with debug_backtrace() and even more
so if you wrap it in its own reusable function.
I don't see the need to implement this in the language since it's
possible to achieve in userland trivially.