Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module name, type name aliasing conflict #396

Closed
4 tasks done
ulitiy opened this issue Aug 30, 2022 · 5 comments · Fixed by #397
Closed
4 tasks done

Module name, type name aliasing conflict #396

ulitiy opened this issue Aug 30, 2022 · 5 comments · Fixed by #397
Labels
type:bug Impaired feature or lacking behavior that is likely assumed

Comments

@ulitiy
Copy link

ulitiy commented Aug 30, 2022

New Issue Checklist

Issue Description

ParseSwift module is named the same as the ParseSwift class, that makes it impossible to write a fully qualified type in case of the naming conflict. And ParseSwift.Subscription already has a conflict with Combine.Subscription.

Steps to reproduce

This means I cannot even specify EnvironmentObject:

// 'Subscription' is ambiguous for type lookup in this context
// Cannot specialize non-generic type 'Subscription'
    @EnvironmentObject var lessons: Subscription<Lesson>
    var cancellables = [AnyCancellable]()
// 'Subscription' is not a member type of struct 'ParseSwift.ParseSwift'
    @EnvironmentObject var lessons: ParseSwift.Subscription<Lesson>
    var cancellables = [AnyCancellable]()

If the module name was different from the class name it could be possible to have
Maybe another option is to have typealiases for conflicting names but it doesn't resolve conflicts with local project names.

AFAIK there's no tool like :: in Swift. The only way I see it can be fixed now by the library user is by importing and aliasing specific types from Combine, and never import Combine when I want to use Subscription. Like this:

typealias MyAnyCancellable = AnyCancellable

Actual Outcome

Errors

Expected Outcome

No errors

Environment

Client

  • Parse Swift SDK version: 4.9.0
  • Xcode version: 13.4.1 (13F100)

Logs

n/a

@parse-github-assistant
Copy link

parse-github-assistant bot commented Aug 30, 2022

Thanks for opening this issue!

  • 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

@cbaker6
Copy link
Contributor

cbaker6 commented Aug 30, 2022

What exactly are you trying to do? For example what code isn’t compiling and how does it differ from the many tests in the test suite? Heres an example using combine:

func testOpen() throws {
guard let client = ParseLiveQuery.defaultClient else {
XCTFail("Should be able to get client")
return
}
client.close()
var subscriptions = Set<AnyCancellable>()
let expectation1 = XCTestExpectation(description: "Send Ping")
let publisher = client.openPublisher(isUserWantsToConnect: true)
.sink(receiveCompletion: { result in
switch result {
case .finished:
XCTFail("Should have produced failure")
case .failure(let error):
XCTAssertNotNil(error) //Should always fail since WS is not intercepted.
}
expectation1.fulfill()
}, receiveValue: { _ in
XCTFail("Should have produced error")
})
publisher.store(in: &subscriptions)
wait(for: [expectation1], timeout: 20.0)
}

Another using Subscription: https://github.com/netreconlab/SnapCat/blob/66bd9a2cecd4e665bc7bca13ce74690d2c613bb2/SnapCat/CustomViewModels/QueryImageViewModel.swift#L14-L340

@ulitiy
Copy link
Author

ulitiy commented Aug 30, 2022

I was trying to use an EnvironmentObject with a Subscription<Lesson> class to reuse the subscription in multiple nested components. It's impossible if Combine is imported because there's Combine.Subscription.

It fails anyways even if I use MyAnyCancellable with No ObservableObject of type Subscription<Lesson> found. somehow.

In your examples you do not use EnvironmentObject with Combine imported at the same time.

Anyways there's a reason why there's no Swift.Swift class (or similar) in the standard libraries – because there would be no way to call Swift.String not causing the error. I understand that many of the libraries conform to the same convention as ParseSwift but it's causing problems, lots of unresolved discussions: https://www.google.com/search?q=swift+module+and+class+name+collision

@cbaker6 cbaker6 added the type:bug Impaired feature or lacking behavior that is likely assumed label Aug 30, 2022
@cbaker6 cbaker6 linked a pull request Aug 30, 2022 that will close this issue
5 tasks
@cbaker6
Copy link
Contributor

cbaker6 commented Aug 30, 2022

Thanks for reporting and describing your issue. The linked PR should address the problem

@ulitiy
Copy link
Author

ulitiy commented Aug 30, 2022

Thank you for the quick response and for working on the library!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Impaired feature or lacking behavior that is likely assumed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants