Add Stringable on storage attributes

[maxhelias]

I didn't want to add the extends to the StorageAttributes interface to avoid breaking changes, but it can be done in the future if you want this feature

[SamMousa]

What's the use case for this?

You'll always need to iterate over the iterable since that won't be properly stringified. So inside your loop you'd be able to do use echo or similar to dump a StorageAttributes to create strings in a very specific format that probably doesn't serve most use cases.

Can you provide some arguments for why this should be added to the library and not just live in some formatting code that lives in consuming projects?

[maxhelias]

Improve the DX. If I remember correctly, I have to array_map the iterator before I can render it as a console table. If the attributes are stringable, it will be automatic

[SamMousa]

If I remember correctly, I have to array_map the iterator before I can render it as a console table.

That's on a different level though, there is an iterable of StorageAttributes objects. In a console table you'd still want to loop over the iterable, or map it to an array. Also, reasonably if you're drawing a table you'd be adding some padding and possibly show the type in a different column.

Where I'm going with this is that the specific formatting you suggest (or any other specific format) will always only be useful in very specific use cases.

I don't think this will affect the DX in any meaningfull way for 99% of the developers.

[maxhelias]

The stringified format can indeed be revised, but making these objects Stringable is a common OOP technique that enhances flexibility. It’s useful for logging, debugging, and simple displays, allowing developers to handle these objects without needing to explicitly map them each time. This improves developer experience in many cases without imposing any specific usage.

[SamMousa]

The stringified format can indeed be revised, but making these objects Stringable is a common OOP technique that enhances flexibility. It’s useful for logging, debugging, and simple displays, allowing developers to handle these objects without needing to explicitly map them each time. This improves developer experience in many cases without imposing any specific usage.

I fully agree with those points, there are downsides as well though:

1. If you don't add it to the interface you cannot assume that a directory listing will always only contain these concrete implementations
2. If you do add them to the interface it's a break in backwards compatibility and the benefit in DX for consumers is inversely correlated with the DX for implementers

Any ideas on how you'd tackle that?

[maxhelias]

@SamMousa I added an annotation to the interface to trigger depreciation for uses of it outside the package.

[SamMousa]

@SamMousa I added an annotation to the interface to trigger depreciation for uses of it outside the package.

You added an annotation of @method that is not a deprecation (and adding a new method to a future version is not a deprecation).

Personally I don't see the added benefit, as I said before, the benefit for consumers is minimal and it forces all implementers to think about this format for their StorageAttributes implementation.

[maxhelias]

You're right, I forgot that it's only with the symfony/error-handler component that depreciation is indicated. But I see that this annotation is already in use, as here: https://github.com/thephpleague/flysystem/blob/3.x/src/FilesystemReader.php#L13-L15

[SamMousa]

It does something else, not a deprecation but help with autocompletion