[2.0] Consider abandoning the polyfill

[rtheunissen]

There are a few reasons why I believe we should consider abandoning the polyfill:

• It's a performance risk. Someone might not realise that they don't have the extension enabled or share code with someone that doesn't have the extension installed, which results in a very inefficient implementation of the structures.
• It's blocking some changes in the extension, like operator overloading on sets (for diff, xor, union and complement) and the ability to allow == to behave like it does for arrays.
• There isn't a good reason for anyone to use the polyfill on purpose. If they don't have access to their environment to install the extension, they shouldn't be using the library at all.
• It's extra work to maintain the polyfill, extension and tests in separate repositories. If we drop the polyfill we can move the tests into the extension repository and tag them together.

[rtheunissen]

One thing to note is that the polyfill also acts as an autocomplete source. If we decide to abandon the polyfill in 2.0, we would need to keep the stubs anyway. Something we could do is maintain a composer package that contains the tests and the stubs, and requires the extension as ext-ds, and have the extension repository require that package. That way we're still separating the extension from the tests and the stubs, and we're enforcing that the extension is installed if a project has the composer package as a dependency.

[kelunik]

Without a polyfill we (amphp) will never use ds. Things must just work for all basic things.

[rtheunissen]

@kelunik but you're taking two steps back by using the polyfill at all. Anyone without knowledge of the extension using amphp will suffer serious performance and memory issues.

Edit: noticed that php-ds is not actually a dependent of amphp?

[kelunik]

Right, we currently don't use it, but if we would, we'd want it to be runnable by default without any additional extensions. It's currently not worth for the few cases we have.

[stepzerosolutions]

With first installation attempt fail, I've installed the extension without any issue on a new php build. I'm new to php-ds and still doing testing, I don't see any reason not to abandoned it if nobody is using it.

[rtheunissen]

@TheCelavi @jkuchar @dantudor @krakjoe @nikic in light of this issue and #8 (Pure PHP implementation), I would like to ask if anyone has any strong opinions here.

In my opinion:

Reasons to abandon:

• No chance that the library decreases performance (either extension or not at all).
• No need to maintain the second implementation - can focus on the extension.
• There isn't a practical reason why anyone would be using the polyfill, eg. if you're in an environment where you don't have access to install the extension, you shouldn't be using the library at all.

Reason to maintain:

• Improves adoption, can play around without installed the extension.
• Allows code to run in an environment where the extension isn't installed.
• Doubles as autocomplete stubs.
• Most of it is already implemented.
• We'll have to maintain it for 1.0 anyway.

[jkuchar]

It was big thing when I was considering if we are going to use phpds interface. For example when there will be new version of php and this extension will not be available (e.g. not maintained anymore) I will still be able to use the app thanks to the polyfill or even fix someting there. I will not be able to fix C source. Polyfill makes me feel much more safe that my app will not be locked on old php version where phpds used to be supported. I use polyfill all the time because I do not want to mess with the compilation process on Windows. I do not care that it is slow. It works. It makes sense to me to NOT have polyfill if phpds makes it into php bundled extensions. (e.g. just enable it in php.ini and go; or just install package and go on linux) Honza Kuchař 23. 7. 2017 v 3:13, Rudi Theunissen <notifications@github.com>:

…

@TheCelavi @jkuchar @dantudor @krakjoe @nikic in light of this issue and #8 (Pure PHP implementation), I would like to ask if anyone has any strong opinions here. In my opinion: Reasons to abandon: No chance that the library decreases performance (either extension or not at all). No need to maintain the second implementation - can focus on the extension. There isn't a practical reason why anyone would be using the polyfill, eg. if you're in an environment where you don't have access to install the extension, you shouldn't be using the library at all. Reason to maintain: Improves adoption, can play around without installed the extension. Allows code to run in an environment where the extension isn't installed. Doubles as autocomplete stubs. Most of it is already implemented. We'll have to maintain it for 1.0 anyway. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rtheunissen]

@jkuchar I think what dawned on me is that you would be better off not upgrading PHP or not using the extension than if you were using the polyfill.

I do not want to mess with the compilation process on Windows

You shouldn't need to at all, there are .dll's in the releases on Github and on PECL here.

[jkuchar]

I didn't know it made it into PHP 7.1 default bundle. Now it feels like something stable. The mission of polyfill - to overcome the fear of getting dependent on new extension whose development can be abandoned - is completed. 25. 7. 2017 v 2:53, Rudi Theunissen <notifications@github.com>:

…

@jkuchar I think what dawned on me is that you're better of either not upgrading PHP or not using the extension than you are using the polyfill. I do not want to mess with the compilation process on Windows You shouldn't need to at all, there are .dll's in the releases. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[rtheunissen]

I didn't know it made it into PHP 7.1 default bundle

Not that I'm aware of, but it's compiled and available on PECL.

The mission of polyfill - to overcome the fear of getting dependent on new extension whose development can be abandoned - is completed.

The mission of the polyfill is:

• Prevent code from not working at all in environments where the extension couldn't be installed or hasn't been installed yet
• Provide IDE autocomplete by having the method signatures in your /vendor
• Provide an easy way for people to "play with" the API without the need to install the extension.

I'm starting to feel like maybe failing hard when the extension is not available is a good thing. Because you'd be well worse off then than if you were using arrays.

I'm not convinced either way yet, so this is still just a consideration. 🤔

[NoodlesNZ]

I agree with abandoning the polyfill. If the performance is not there then it's not worth having (it defeats the purpose of using ds). Maintaining the polyfill takes effort away from the extension.

It shouldn't be that hard to maintain stubs for autocomplete.