Swifterswift: Poll: Add ss prefix to all extensions
While adding the SS prefix to all extensions will make them less readable, it could bring more compatibility with 3rd party libraries
Example:
[1, 2, 3].ssRandomItem
// or
[1, 2, 3].ss.randomItem
instead of:
[1, 2, 3].randomItem
omaralbeik
All 3 comments
Despite this could be convenient to find quickly some extensions, it remove a lot of fluency which is one of the best thing in this repo !
Alex293
on 6 Jun 2017
I'm opposed to this. Most 3rd party libraries keep the extensions used to build the library internal so we won't have any conflicts there.
The problem comes with using a library that solves the same problem SwifterSwift does.
e.g) using SwifterSwift Date extensions and another Date library
In this scenario, the user should really only import the extended SwifterSwift types on a type by type basis. I could probably add a section to the README explaining this.
CocoaPods subspecs could help but only slightly. The real benefit of CocoaPods subspecs is reducing the dependency and binary size.
SD10
on 6 Jun 2017
Community voted not to add this feature
omaralbeik
on 13 Jun 2017
Related issues
fanglinwei
路
3Comments
omaralbeik
路
5Comments
pawurb
路
3Comments
omaralbeik
路
5Comments
g001613001
路
5Comments
Most helpful comment
I'm opposed to this. Most 3rd party libraries keep the extensions used to build the library internal so we won't have any conflicts there.
The problem comes with using a library that solves the same problem SwifterSwift does.
e.g) using SwifterSwift Date extensions and another Date library
In this scenario, the user should really only import the extended SwifterSwift types on a type by type basis. I could probably add a section to the README explaining this.
CocoaPods subspecs could help but only slightly. The real benefit of CocoaPods subspecs is reducing the dependency and binary size.