Strange Behavior Of only()

[MannikJ]

I recently started migrating from spatie/data-transfer-object which I had enhanced quite a lot. Many parts I added can now be omitted, because they are already part of this package, which is very good.

But there are some areas in which I find this packages behaves very counter-intuitive.
One thing which that has cost me nerves is how the only function behaves:

1. I find it quite dangerous to store the only values on the data object itself so that it will affect all following calls as well. I see this feature rather as an on the fly conversion like implemented in Eloquent or the data-transfer-object package as well. If you pass the data object and call only in between, it will affect all other areas in the program which reference the same object.
2. It does not even behave consequently. If you have nested objects, and set the only values on some nested data object, but call toArray() on the parent, the only values of the nested objects are just ignored.
3. Only generally behaves very strange with nested objects. I appears that you have to list each nested property with dot notation, everything not explicitly listed will be ignored. You can not easily include a complete nested object with all its nested nested data when using only.

I still have the feeling that I have a misunderstanding of how I am supposed to use this feature. So please explain in case I got something wrong!

For now I have implemented a workaround on my base data class, that I can use when transforming the data object to an array:

    public function toArray(array|string ...$only): array
    {
        $result = parent::toArray();

        if ($only) {
            $trimmed = [];

            foreach (is_array($only) ? $only : func_get_args() as $path) {
                if (Arr::has($result, $path)) {
                    Arr::set($trimmed, $path, Arr::get($result, $path));
                }
            }

            $result = $trimmed;
        }

        return $result;
    }

[rubenvanassche]

1. Yes that's how it has been since the beginning, I don't think we want to change such behavior right now.
2. We're reworking this in the next major version of data.
3. Have you seen the * operator?

[MannikJ]

Thank for your clarifications!

I am actually quite surprised that the current behavior has not yet evoked a lot of complaints ;)

Of course I understand that changing a part like this would be quite a major change that needs to be well-thought, but I'm fine with my workaround for now and I actually feel safer doing it this way and not mess with the instance forever.

Good to know that 3. can be solved by using the * operator.