ReactPHP v3 is going to happen! 🎉

We're committed to work on the next major version of ReactPHP. We've started working on this a while ago and believe it's time to finally make this public and give people a chance to see what we're up to and to contribute. In order to show the ongoing development towards ReactPHP v3, we're using dedicated roadmap tickets (like this one) for each component.

Our plans towards Cache v3

• ✅ Create 3.x branch #57
  Once this is created, we can start working on the new v3.0.0 milestone. The default branch will be 3.x and the previous 1.x branch still stay in place at least until v3.0.0 is released.

• ✅ Require PHP 7.1+ and recommend PHP 8.1+ #58
  Time to upgrade! The new v3 will make use of newer language features, so we will upgrade to PHP 7.1+ as a minimum requirement (to run absolutely anywhere) and recommend PHP 8.1+ looking forward (Fibers).

• ✅ Upgrade to require Promise v3 #59
  All upcoming v3 components should require any other ReactPHP components from the same major version or above, so we can deprecate legacy versions in the future.

• ✅ Type-Safe APIs with PHPStan on max level #60 #61
  All our public APIs should use native type declarations to avoid invalid API usage and guide IDEs and static analysis tools.

• Blocking APIs and async APIs
  We will rename the existing async APIs and then add new synchronous APIs using the previous names. This means you get the best of both worlds and can use whichever style works best for your use case. Each change will have a clear upgrade path described.

• Prepare any remaining v1 releases
  Before tagging a v3 release, we should make a clear cut to ease upgrading. We should finish any v1 releases already prepared until v3 is ready.

• Release reactphp/cache v3.0.0
  Planned around mid-2024, approaching our 12th birthday? To ensure a smooth release, we will coordinate the process across all our components.

How you can help

We're optimistic to get the above things done in the near future, so this ticket aims to serve as a basic overview and is subject to change as we progress. For more details, see also the milestone links and any referenced tickets. If you have any additional input for ReactPHP v3, we invite you to join our discussion about the roadmap for the next major version.

Working on the next major version involves a lot of work and we're always looking for sponsors to allow us spending more time on ReactPHP. Check out ReactPHP's sponsors profile and consider supporting the ongoing development ❤️

We'll do our best to keep this ticket updated as we make progress. To keep things organized, let's try to limit the discussions in here and please use new tickets and discussions for input. Help us spread the word! We are excited to move forward together! 🚀

I've been thinking about how we can improve caching and what I would really like to see is TTL support in cache adapters. With that the DNS component only store a message contents in the cache and gives it a TTL. The DNS component also doesn't have to do the GC as that becomes the responsibility of the adapter. In cache of a redis adapter redis can take care of that. But for the array cache another mechanism has to be devised.

I know it's not part of PSR-16 and sadly I don't know why because some cache controller could benefit from this function.

I would expect that's for a simple cache like ArrayCache it would be a simple loop on all values. The same using all($getArray); would be an overkill and I would expect an performance impact.

If no plans to add it I'm happy too.

Like PSR-16

I translated the Chinese Edition of the ReactPHP-Cache document .

https://www.yuque.com/lvsi/reactphp-cache

i think its good if reactphp/cache has bridge to PSR-6 (Caching Interface) and PSR-16 (Simple Cache)

what do you think?

Currently, get() returns a rejected promise on a cache miss. Since rejection is the asynchronous equivalent of throwing an exception in synchronous code, it behaves like

public function get($key)
{
    if (!isset($this->data[$key])) {
        throw new \Exception()
    }

    return $this->data[$key];
}

Is this the intended behavior?

We should look into providing a stable (in the sense of SemVer) release for this component.

From looking at the version history it looks like the very first tagged release could in fact already have been a v1.0.0.

This ticket aims to serve as an RFC.

As shortly discussed here we're considering to return PromiseInterface for set and remove methods. Do You have any reasons to not agree?

Suggested by @clue

The ArrayCache keeps growing and growing when new data is added to it. We should probably add an optional parameter to limit the cache size and implement a simple LRU algorithm to remove "old" entries.