'File' is not a member type of 'S3'

[ghost]

Using type 'File.Response' generates error 'File' is ambiguous for type lookup in this context. Qualifying it with S3, 'S3.File.Response', generates error 'File' is not a member type of 'S3'.

For example, the response returned in the closure in the code below returns the following error:

expression produced error: error: /var/folders/_p/_xk10nks06103l9_0lsly4c40000gn/T/expr1-8c0981..swift:1:68: error: 'File' is not a member type of 'S3'
Swift._DebuggerSupport.stringForPrintObject(Swift.UnsafePointer<S3.File.Response>(bitPattern: 0x1064fc200)!.pointee)

public func save(file data: Data, to path: String, mime: MediaType, on container: Container) throws -> EventLoopFuture<Void> { let file = File.Upload.init(data: data, destination: path, access: .publicRead, mime: mime.description) return try s3.put(file: file, on: container).map(to: Void.self) { response in return Void() }.catchMap({ error in throw Error.failedWriting(path, error) }) }

It seems like 'put(file:, on:)' is not returning the expected type of Future<File.Response>.

[zdnk]

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...

[ghost]

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

[rafiki270]

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?

[ghost]

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

[rafiki270]

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

[ghost]

Perfect.

[zdnk]

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

[rafiki270]

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

[zdnk]

We will have again conflict with Vapor then :/

[rafiki270]

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

[rafiki270]

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

[zdnk]

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.

[scinfu]

Any News?

[louisdeb]

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

import struct S3.File