Better Interface Segregation (Future Version?)

[designermonkey]

Better Interface Segregation (Future Version?)

[rtheunissen]

This is great, thank you for taking the time.

I have a draft API sketched out for a v2 that I am very eager to get around to. I think as part of that, when all is said and done, will be a push to either merge into core or push for default extension like json.

Could you maybe justify some of the design decisions here? I would like to know why the hierarchy is the way it is, to better understand your experience and use that to inform the next phase.

Once I'm happy with the API I'll post it for feedback and hopefully arrive at some consensus to then move forward with implementation and testing.

[designermonkey]

Could you maybe justify some of the design decisions here? I would like to know why the hierarchy is the way it is

That's a good question. I guess I wanted to group the methods on each class a little better. That being said, it still doesn't help my actual use case, which I will explain...

We are using Swoole, and I wanted to create a ConcurrentMap class to allow proper memory protection. I saw that there wasn't an interface I could use to allow the use of Ds\Map or my own ConcurrentMap interchangeably, so I tried to figure out what the commonalities were and came up with the above.

As I point out, this is still not helping as I still can't see an interface that allows me to decorate your Ds\Map with my ConcurrentMap and use methods like put and get etc as they are unique to Map, so back to the design phase for my classes for me :)

[designermonkey]

I just realised after I wrote that, that I can use ArrayAccess. I've never been a fan of it as I prefer objects, but it is what it is I guess.