Package proposal: PHP Collections Framework

[john.wi...@rocky.edu]

Hey guys,

A while back I created a package called collections, after much deliberation and looking through existing collections packages.

The closest package to mine is probably icecave/collections, which was inspired by C# and C++. Unfortunately, it was last updated two years ago.

My collections framework was almost entirely modeled after the Java Collections Framework, with a few additions (like tuple and tree), and a bit better organized than icecave.

As a side effect of being primarily modeled from the JCF, the api takes into account certain efficiency operations which are nonsensical using standard PHP arrays (like "offer"). However, those efficiencies allow for broad compatibility if the underlying structures were written in c and simply bound to PHP.

I think it would make an excellent addition to the league.

I would appreciate any feedback you have about improvements for the package.

Thanks,

John Mark

[john.wi...@rocky.edu]

Just for fun, I compared my implementation of HashSet against a naive implementation of an array as a set, and against the icecave/collections implementation of Set. Here are the results: http://i.imgur.com/ax7diVL.png.

Unsurprisingly, my HashSet astronomically outperformed the naive implementation. What was surprising is that the icecave Set did the worse. It's doing deep iterative object comparisons, rather than simply using a digest.

Here is the code I used for the comparison: http://pastebin.com/JUqeTzFV. Here is the raw data I used for the graph: http://pastebin.com/cDVHtpAZ.

My HashSet can run 20,000,000 add operations and guarantee uniqueness in about 45 seconds. If we extrapolate a bit, it would take the standard array about 25 minutes, and the IceCave Set about 33 minutes. That is a ridiculous performance difference.

Thanks again for your consideration.

[ignace nyamagana butera]

Hi John,

I've look at your library and liked it bu my biggest complain is why didn't you take advantage of PHP SPL objects and interfaces. Have a look at this work for instance : https://github.com/morrisonlevi/SPL-Collections

PS: I assume that you will convert your code to be PSR-2 compliant and require at least PHP5.5 or PHP5.6 for your first stable release.

Ignace

[john.wi...@rocky.edu]

I initially didn't take advantage because there is a certain level of inconsistency between my collections and how the SPL stuff is structured. 

The two biggest spl interfaces are ArrayAccess and Iterator.

• Not every collection is accessible via getting some index, like sets or queues (mine queues are through virtue of implementation). 
• The fact that the ArrayAccess interface combined a set and append operation bothered me.
• Iterator couples itself to the iterable thing, 
• It breaks the Single Responsibility Principle
• It introduces state

Now, despite my objections to ArrayAccess, it *does* provide some nice syntactic sugar. To that end, I've added it to ArrayList and HashMap. Lists and maps can support it, even if it isn't meaningful in other data structures.

One of the major objectives of this library is to do what PHP does not: introduce consistency and expected behavior. Because of that, I'm having trouble rationalizing the introduction of Iterator. Not that I'm complete opposed to it, just that I need to work through what the expected behavior is in all the various circumstances, and what the best implementation would be.

I will convert to PSR-2. I'm not sure what the benefit of requiring 5.5 or 5.6 is. My library will certainly run with them, but it will also run with 5.3. My intention would be to release with the lowest reasonable version, and then simply tick up versions as it becomes incompatible with older versions. What is the benefit of forcing a newer version?

[Christopher Pitt]

There is already a ton of work going on in this area, by Rudi Thuinessen and Joe Watkins. I expect a fantastic extension or even additions to SPL within a year...

[john.wi...@rocky.edu]

Hey Chris,

I don't suppose you have a reference to the work they are doing? The code itself would be great, but barring that a blog post would work. I would love to see what other solutions are being worked on.

Thanks.

[Christopher Pitt]

https://medium.com/@rtheunissen/efficient-data-structures-for-php-7-9dda7af674cd

[john.wi...@rocky.edu]

That is awesome, thank you for pointing me in that direction. I'll withdraw this application, and see if I can help out with that extension!

On Saturday, April 16, 2016 at 5:59:44 PM UTC-7, Christopher Pitt wrote:

https://medium.com/@rtheunissen/efficient-data-structures-for-php-7-9dda7af674cd

[Christopher Pitt]

I'm sure Rudi and Joe would appreciate the help. :)