I absolutely agree that unpacking objects to functions is a bad idea,
my use case for this is different.
Take for example that you have API endpoint that returns user balance
```php
readonly class Balance
{
public function __construct(
public float $debt,
public float $credit,
) {}
}
```
And a service that do all the logic
```php
interface UserService
{
public function getBalance(): Balance;
}
```
But you also have endpoint for general user information that includes
flattened balance (better thing would be to just have balance
property, but API already designed and you can't change it)
```php
readonly class Profile
{
public function __construct(
public string $name,
public float $debt,
public float $credit,
) {}
}
```
So a logical thing to do is just unpack (flatten) balance object
```php
return new Profile(
...$service->getBalance(),
name: $name,
);
```
чт, 14 нояб. 2024 г. в 22:28, Larry Garfield <la...@garfieldtech.com>:
>
> On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote:
> > Am 14.11.2024 um 10:59 schrieb Marco Pivetta <ocram...@gmail.com>:
> >> On Thu, 14 Nov 2024, 11:29 MrMeshok, <ilyaorlov...@gmail.com> wrote:
> >>> Hello, Internals!
> >>>
> >>> As you know if you try to unpack a regular object (`...$object`) you will
> >>> get an error: Only arrays and Traversables can be unpacked.
> >>> I don't really see a reason for this restriction, because foreach on
> >>> objects works perfectly fine, so I made a feature request on GitHub to
> >>> change this behavior (https://github.com/php/php-src/issues/16038) and
> >>> was advised to see opinions on this here.
> >>> So, what do you think? And does this change require RFC?
> >>
> >> TBH, foreach on objects is already quite an abomination in itself 😬
> >
> > It is a bit less weird if you use value objects or json data in object form.
> > I would be careful to judge how other people use the language, just saying
> > ;-)
> >
> > - Chris
>
> Judging how one should use a language is a core component of language design.
>
> I'm with Marco on this one, and I'd be more than happy to get rid of
> foreach($object), too. It's way, way more complicated a topic than you think.
>
> How does visibility play into it?
> Should hooks be invoked or no?
> Do references play into anything?
>
> Those are some of the questions we had to deal with for hooks and foreach().
> It's non-trivial. You'd need to address all the same edgy issues here, too.
>
> And that's assuming it's even a good idea, which I don't think it is. If you
> are using a value object to define unordered arguments, just pass the value
> object itself. If the receiving function can't handle that, then it is
> simple enough that you don't need a value object. If that's not the case,
> then your code design is bad and the language should not try to paper over
> that for you. Either simplify the function or adapt it to use a value object
> directly. (With union types you can even do so in a BC fashion much of the
> time.)
>
> --Larry Garfield
