LiveUI / S3

S3 Client written in Swift
MIT License
94 stars 60 forks source link

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

Open ghost opened 6 years ago

ghost commented 6 years ago

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.

zdnk commented 6 years ago

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 commented 6 years ago

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

rafiki270 commented 6 years ago

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 commented 6 years ago

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

rafiki270 commented 6 years ago

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 commented 6 years ago

Perfect.

zdnk commented 6 years ago

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

rafiki270 commented 6 years ago

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

zdnk commented 6 years ago

We will have again conflict with Vapor then :/

rafiki270 commented 6 years ago

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

rafiki270 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

Any News?

louisdeb commented 4 years ago

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

import struct S3.File