Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support DataStructure (ds) extension #50

Open
ghost opened this issue Feb 6, 2019 · 4 comments
Open

Support DataStructure (ds) extension #50

ghost opened this issue Feb 6, 2019 · 4 comments

Comments

@ghost
Copy link

ghost commented Feb 6, 2019

Is your feature request related to a problem? Please describe.

No 馃樅

Describe the solution you'd like

Integration with the Data Structure extension Ext Github Ext Docs

This would be a tremendous win for memory efficiency, in particular around the Map/Set Collection, but even more generally if you use a Vector, I would explain some more, but there is a nice medium post that does an even better job than I could here

It also has some nice builtin queues like:

It even has a polyfill (right now, this might go away in 2.0, fair warning)

DS Polyfill

One other (quick) suggestion, a Doctrine Collections style Collections library based on this, but with added support for Criteria and predefined Doctrine types 馃榾

Describe alternatives you've considered

Data Structures Extension, as noted.

Additional context

For context, I deal a lot with shoveling data around from very large databases and I have found the ext-ds a life saver, but sometimes I need some plain PHP style collections (like those offered in this library) and even the short time i have used this library I have found it relatively straightforward to work with.

I'd be happy over the coming weeks to collaborate on this 馃憤

Just wanted to open the conversation 馃槃

@ghost ghost added the enhancement label Feb 6, 2019
@ramsey
Copy link
Owner

ramsey commented Feb 7, 2019

I like this idea, though I wouldn't want to make the library dependent on an extension, and though there's a polyfill, you've noted that it might go away. We could change the internals of this library to use composition, composing ext-ds, if it's available, and using pure PHP, if not.

What do you think?

@ghost
Copy link
Author

ghost commented Feb 7, 2019

@ramsey

I think we could change the internals to be variable based on whether or not the extension is enabled, it would be the most efficient path here I think. We could do some class aliasing based on the extension availability for instance, so we just check for the DS class and go from there.

One other thing I thought of, is instead of simply having a private array, why not have a base class that extends ArrayObject ? I think the SPL extension is included by default in all releases of 7+

This way, we can have nice helper methods on the data structure itself, for example.

@ramsey
Copy link
Owner

ramsey commented Feb 7, 2019

why not have a base class that extends ArrayObject ? I think the SPL extension is included by default in all releases of 7+

ArrayObject has been in the PHP core since version 5.0.0. 馃槃

I purposefully decided not to extend ArrayObject with this library. There's nothing wrong with ArrayObject, but I didn't want to tightly couple this implementation to it, in much the same way I don't want to tightly couple to the DS classes. Pure PHP now provides enough speed and power to handle these operations, and IMO, SPL no longer really needs to be part of the core. It could be moved into userland libraries with little-to-no performance loss.

@ghost
Copy link
Author

ghost commented Feb 12, 2019

@ramsey

Makes sense!

Well, what do you think the best, most straightforward way for us to integrate this will be? Should we alias things based on availability or have a sub-folder that is DS specific?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant