Re: RFC: Locked Classes
| From: | Marco Pivetta | Date: | Sun, 10 Mar 2019 19:46:08 +0000 |
| Subject: | Re: RFC: Locked Classes | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104628@lists.php.net to get a copy of this message | ||
Typical scenario (works for either of the properties - note that typed
properties that aren't nullable and have no default value also behave the
same way):
class Foo {
private int $a;
private $b;
public function __construct() {
unset($this->b);
}
public function __get(string $name) {
$this->a = 123
$this->b = 'abc';
return $this->$name;
}
public function saySomething() : string {
return $this->a . $this->b;
}
}
echo (new Foo())->saySomething();
https://3v4l.org/Rn39Q (note: 3v4l doesn't have 7.4, so I
simplified it a
bit)
@rowan: I've stated it multiple times in the past, but if the mechanism is
to be removed, then it should be replaced with a language-level concept of
laziness then.
On Sun, 10 Mar 2019, 20:32 Larry Garfield, <larry@garfieldtech.com> wrote:
> On Sun, Mar 10, 2019, at 1:52 PM, Marco Pivetta wrote:
> > Hi Rowan,
> >
> > Overall good idea, except that I disagree with the
unset()
> > being
> > disabled: that bit is strictly required for lazy-loading purposes, and
> > mostly harmless for userland ("normal" people don't do it, libraries do
> it).
> >
> > Besides that (blocker for me), if this RFC would be enforced in my coding
> > standards of choice 👍
> >
> > Does anybody know if this has potential for engine optimizations?
>
> Marco, have you an example of such lazy-loading tricks? I'm not familiar
> with them but would like to be...
>
> I'm overall +1 here as well, as I am for most things that allow me to make
> my code stricter and pickier. (I don't have a strong feeling on unset()
> either way.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>