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
Consider refactoring to protocol extensions #387
Comments
@DanielAsher I get your concern. I believe the namespace pollution comes from adding the library as a target dependency in your code. Alternatively if you use something like pods, IIRC they pull the source down and there is a compilation conflict. My only concern is breaking the existing userspace. @goktugyil @lfarah @piv199 - What do you guys think. If we take this up, we would have to dedicate an entire release for this. |
This would require heavy refactoring, will change the behaviour for all users. And I'm not sure if will actually work for all cases. We try to differentiate extensions from standard libraries and make it clear with the docs that its an extension to minimize the problem. |
Can we at least find a quick fix for #386's |
I presume the fix for this would be to remove this
If yes I will remove it ASAP. |
But if it's deprecated, why is @DanielAsher getting an error? |
I dont know why he is still getting an error. |
@Khalian - that for the quick PR and merge. I believe that deprecated extension methods still override standard library implementations. Could you remove the following deprecated extension method from the library:
this should complete and close the issue. Thanks! |
Ok will do |
One more! Please remove deprecated |
Removed removeAll in PR. |
It looks like Swift 3.1 will greatly simplify refactoring to finely-grained protocol extensions with https://bugs.swift.org/browse/SR-1009 being implement. Constrained extensions allow same-type constraints so refactoring StringExtension.swift simply requires:
|
Hey @DanielAsher, that looks really cool! |
Can we close this, @Khalian? |
@lfarah We could but @DanielAsher has requested we deprecate : https://github.com/goktugyil/EZSwiftExtensions/blob/928d825dcc5002f468d8cfc0b94b98a5910f160c/Sources/ArrayExtensions.swift#L135 We can have a quick discussion on the merits and demerits of the same. |
Hi,
as a follow on from #386 I wanted to know if any consideration has been given to refactoring the framework to use protocol extensions. This could allow per-file limited imports of specific features.
As an example, currently
Array.get
is defined as:This seems to be imported into a file without any explicit
import EZSwiftExtensions
declaration.Could this be refactored to:
which would allow a file to either
import protocol EZSwiftExtensions.EZArray
(limited import)import EZSwiftExtensions
(full import)I'm not sure this would solve the problem (I don't really understand the subtleties of swift's import mechanism) or why a file would import EZSwiftExtensions without an explicit
import EZSwiftExtensions
declaration.Thanks again!
The text was updated successfully, but these errors were encountered: