Swifterswift: Array shuffle method is wrong and ineficient

[abelondev]

1. array shuffle doesn't have optimal implementation as it relies on sort
2. It is just wrong it can't return the same, so output is not fully random.

[SD10]

@abelondev Do you have a suggestion for a better implementation?

Regarding your second point, I don't think the intention is for the output to be completely random, but rather to mix up the elements in the array. I believe that's why the check to make sure the output is different was included.

A boolean parameter defaulting to false could be included for this method to allow it to return the original output.

[abelondev]

1. Current algo has O(n log n) complexity at best. You can find o(n) algos here: http://stackoverflow.com/questions/37843647/shuffle-array-swift-3

2. German Enigma coding machine was broken just because it had that "if" which doesn't allow to return the same result.

[abelondev]

Implementation also will hang on the array with the length of one

[SD10]

Ok, thank you for pointing this out 👍 Feel free to submit a Pull Request

[abelondev]

I think the project should be split into independent projects: CocoaExtensions and DataStructure extension. So the last could be reusable everywhere and not just for iOS. It is different type of expertise to write UIKit extensions and Data Structure ones. It is difficult achieve excellence in both.

[omaralbeik]

One way to get around this at the moment is to copy only the extensions you want to use.
The other way to do this is using Cocoapods subspecs, I'm working on splitting the project into 3 sub-projects, so instead of integrating the entire library, you can integrate only what you want to use. like you can do with Firebase.

Project will be spilled into 3 projects

• SwifterSwift/FoundationExtensions
• SwifterSwift/UIKitExtensions
• SwifterSwift/CocoaExtensions

Changes are most probably coming late March or early April as part of v2.0 as I'm very busy with other projects at the moment.

Personally I don't think splitting the project into independent projects is a good idea, I do prefer the subspecs way, what do you think guys?

[SD10]

@omaralbeik This has been on my mind as well as I'd like to limit the integration of the entire library when only needing a few extensions.

• I do not like the idea of splitting this up into independent projects because I think it could diminish support for this project from the community.

• I LOVE the idea of using Cocoapods subspecs. Organizing the project this way would allow us to create a a subspec for any other frameworks we decide to extend in the future and would be highly maintainable.

[abelondev]

Your competitors

1. https://github.com/ovenbits/Alexandria/ uses subspec for that
2. https://github.com/pNre/ExSwift/ has more and better collection extension

[omaralbeik]

@abelondev So far all you did was just talking, well, just pointing to errors without fixing them (or at least helping) doesn't help anyone here!
Feel free to dive into the code and contribute to the project (actual contributions not just talking)
or just use one of my competitors libraries for now :)

[abelondev]

You didn't get my point. I'll wait when project will be split. Writing UIKit extension and DataStructure extension is different kind of work. I wish I had splitter in some way project to just focus on DataStructrure improvements. It also means split Unit test projects.

[omaralbeik]

I DO understand your point @abelondev, and I also think separating the project into 3 project is a good idea, in fact the only thing stopping me from doing it is time as I have other projects that I'm working on right now
My message to you was if you want to improve the DataStructrure part of the library, please do it in code rather than just saying, you can start working on DataStructrure without worrying about UIKit or Cocoa for now, I don't understand why this should effect your improvements!

[SD10]

@omaralbeik Just to confirm
When you talk about separating the project you mean by using Cocoapods sub-specs?
I don't want to split this project another way because I think it will diminish support.
If we keep it centralized it will allow more people to rally behind it and is easier to find.

Also, this lets us add extensions to other frameworks in the future without having to create a new project for only a handful of extensions.

@abelondev There are nearly 3,000 stars on this project. I think there are plenty people to focus on what each one of us is good at.

If your specialty is optimizing performance, then please make contributions that are not verbal but rather improve the code base. It is easy to point out performance flaws in almost any open source project but something different to actually do something about it.

[omaralbeik]

@SD10 exactly, by separating I mean using Cocoapods sub-specs