Inconsistent return value from `Filesystem#listKeys()`

[ianfp]

Adapter\AwsS3#listKeys() returns a flat array of keys, but the fallback implementation in Filesystem#listKeys() returns a nested array like so:

array(
    'keys' => array(...),
    'dirs' => array(...),
)

This basically exposes implementation details (namely, the adapter) to the user of the library, and forces the user to check which structure he's getting back.

Possible solutions:

1. Make AwsS3 and similar return a nested array where dirs is always an empty array.
2. Add a listDirs() method to Filesystem; both it and listKeys() should return flat arrays.

[benoitMariaux]

:+1:

[mikemix]

Still happens, still not fixed

[adelowo]

@NiR- I would like to fix this. Which of the solutions in the original comment should we go with ? 1 sounds ok. 2 seems a BC

[malarzm]

FWIW both solutions are BC breaks as they change existing behaviour.

[ianfp]

@malarzm is right. Here's a solution 3 that would perserve BC:

Add two methods: listDirs() and listKeysOnly() (or something like that) that return flat arrays of directories and regular files, respectively. Deprecate listKeys() in favour of listKeysOnly(). Then, in version 1.0, change the behaviour of listKeys() to be identical to listKeysOnly() and deprecate listKeysOnly() since it has an ugly name. Then remove listKeysOnly() in v2.0.

Or, you could just implement solution two as originally stated, even though it breaks BC, because Gaufrette is still in version 0.x and is therefore allowed to break BC.

[akerouanton]

To give a better insight about current state of Gaufrette: we try to not merge breaking BC changes into v0.x so users can update from one minor to another seamlessly. In the other hand we have been working on a new v1.0 branch and one of its goal is to fix inconsistencies in adapters/filesystem APIs and how adapters behave. Right now we would consider any fix for the current issue as breaking BC for AwsS3 adapter. But this issue clearly must be addressed for the v1.0.

Now that said, I think the best move would be to remove the concept of directories. Gaufrette abstracts how files are stored, mostly on cloud providers, the exceptions are with filesystem and ftp. To keep Gaufrette consistent we need to provide the common base across adapters, not more. Thus directories is only an implementation detail for filesystem and ftp adapters and should be hidden from any API.

I'll create some issues about what we currently oversee for v1.0 and that should be addressed toning/tomorrow, hoping interested people could more easily spot how they could help.

Thanks for bringing my attention on this issue :+1:

EDIT: Btw I think we should keep the ability to filter based on a prefix, like current listKeys method.