On Thu, Mar 16, 2023, at 5:06 PM, Rowan Tommins wrote:
> On 16/03/2023 17:59, Nicolas Grekas wrote:
>> We could define the "use" as declaring + setting the properties before
>> the constructor is called, if any.
>> But I'm also fine making both constructs conflict: when there is a
>> constructor, the boilerplate saved by the "use" becomes really low.
>> No strong opinion either. There could be other factors to consider.
>
>
> The main advantage of generating an actual constructor is that no change
> is needed to the shared object initialization code, which could be
> complex and even have performance impact. The only new logic would be in
> compiling the class entry and putting the arguments into the "new
> class(...)" statement.
>
> The more I think about it, the more I'm leaning to just blocking custom
> constructors, and saying you can either have the use() short-hand, or
> you can have custom initialization. Additional functionality can always
> be added in later if someone comes up with a clean implementation and a
> good use case.
Wouldn't the functionality described boil down to essentially just
materializing into a few extra lines in the constructor? At least to my
ignorant non-engine brain it seems straightforward to have this:
$a = 1;
$b = 2;
$c = 3;
$o = new class ($a, $b) use ($c) {
public function __construct(private int $a, private int $b) {}
public function something() {}
}
Desugar to this:
$c = class ($a, $b) use ($c) {
private $c;
public function __construct(private int $a, private int $b) {
$this->c = 3; // By value only, so this should be fine?
}
public function something() {}
}
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
