Re: Proposal: Shorthand initialization and destructuring of associative arrays

On Mon, Sep 27, 2021 at 11:27 AM Konrad Baumgart <konrad@baumgart.pl> wrote: > I was recently developing with js/ts and I liked the ease of returning > multiple items from a function as an object, while still preserving > their name. > I recently encountered this as well in Typescript. I believe the syntax is something like this? ```js const someProperty = "something"; const foo = { someProperty, anotherProperty: "Something else", }; // same as const foo = { someProperty: someProperty, anotherProperty: "Something else", }; ``` Obviously this won't work with PHP arrays, which is probably why you decided for => $someProperty. I'm a big no-no when it comes to compact() and extract(). These functions make my life hell. Despite knowing what they do, it still takes me a lot of reading to try and figure out what they do. Even now I will have to go to the documentation to understand exactly how either of them work. Renaming a variable in a certain scope should not break something outside of that scope, and I see this as a big problem in the proposal. When I take your example, spot the error that will cause everything to break runtime with limited static analysis to let you know (hint: missing a g in the first variable). ```php return [ => $dailyAgregations, => $weeklyAggregations]; ``` Refactoring tools could just ignore the outside scope and automatically change it, yet this won't solve anything for text find and replace. ```php return [ 'dailyAggregations' => $theNewVariableName, => $weeklyAggregations, ]; ``` If something like this were to be introduced, I'd happily see it happen with anonymous objects and interfaces accepting properties: ```php interface DashboardAggregations { public readonly array $dailyAggregations; public readonly array $weeklyAggregations; } function getDashboardData() : DashboardAggregations { $dailyAggregations = []; $weeklyAggregations = []; // ... return { $dailyAggregations, $weeklyAggregations, }; // same as return { dailyAggregations: $dailyAggregations, weeklyAggregations: $weeklyAggregations, }; // same as (if properties in interfaces were allowed) return new class($dailyAggregations, $weeklyAggregations) implements DashboardAggregations { public function __construct( public readonly array $dailyAggregations, public readonly array $weeklyAggregations, ) {} }; } ``` If you then really need the destructuring, you could do something like this (just a random syntax chosen), though I'd still be in favor of leaving this aside as you now have a nice object with properties that are accessible. ```php {$dailyAggregations, $weeklyAggregations} = getDashboardData(); ``` This way php could verify the return value with the return type, and static analyzers can determine the structure of what's to be returned. Imo this functionality is not worth the headache with arrays. That said, it feels like this proposal is more of a tuple/multiple return.