'File' is not a member type of 'S3' about s3 HOT 14 OPEN

When hit with the File is ambiguous in this context, I resolved it by adding the following import statement:

import struct S3.File

from s3.

I strongly suggest to rename File to slomething else like S3File, FileObject, S3Object or anything else. What do you think @rafiki270?

Right now it collides with Vapor directly, and it can collide with so many more libraries...

from s3.

Renaming File to S3File sounds like the best option to me.

from s3.

I believe renaming the S3 class so it doesn't bear the name of the package. It is a bad practise (which I wasn't aware of at the time of making the library) for the reasons of being unable to namespace.

Regarding the struct names, I strongly support the most obvious names even if a possible conflict with a sister package is available.

I will be back in the coding den next week and will make the change unless someone would like to help and make a PR beforehand?

from s3.

So what will the new name for the S3 File class be?

from s3.

File ... but you will be able to do S3.File to namespace as S3 won't be the name of the client but the package

from s3.

Perfect.

from s3.

What name would you like it to have? S3Client, S3Api? Please dont say Client :D :D

from s3.

Just Client ... S3Client is already a protocol which would probably deserve a rename as well tbh

from s3.

We will have again conflict with Vapor then :/

from s3.

We won't as we'll be able to namespace

from s3.

Client, File, Object ... all of that should be possible in any package ... you don't have to name your objects with prefixes just to make sure someone's else lib won't conflict with your naming conventions like we did in ObjC

from s3.

I do understand and agree most of the times. They are not package prefixes. For me they are specialozation in this case. You are clearly static that it is S3 client or file. But, I agree with you as this is S3 package only.

from s3.

Any News?

from s3.