A simple handler solution

There is a lot to like here. However, the single line functions (like cache_get) need to distill target information from parameters, which for cache is going to be $table, but for fields it'll be $field->type. This approach will let the casual Drupal developer need not to bother with OOP but those who actually provide the handlers will get an interface (yes we need interfaces) and that's good. The system is simple enough. I will work on this (a lot) today.

This is indeed a simple system, it's like 30 lines. A little in bootstrap.inc for handler which determines the necessary class and instantiates it, loading a file as necessary, a little in common.inc for the builder and a little in system.module defining the 'cache' slot. 'cache' conversion is for demonstration. The rest can be in followup patches.

Fixed default.settings.php which has the nice effect of making the thing working :) also fixed a bit in the API docs.

This version is much closer to mfer's and has a set/get too! hook_slot_info now only provides info. I have called the other hook_handler though. If we want , we could store only the class not an array('class' => $class) for further memory savings.

Addressed mfer's concerns.

Posted the wrong patch, handler_del was left out.

I didn't realize this got split into another issue. So, this is kinda an updated post from the other issue because at this point this is patch is getting closer to #363787: Plugins: Swappable subsystems for core. I still have some serious concerns about storing the $handler information in the variable system. We could potentially be storing a good bit of information in this array. Handlers seem to be the sort of thing that could be used in all sorts of contrib modules. Imagine if Views, CCK and ubercart or ecommerce end up using them and you have a site using all of those handlers... on top of the core handlers... that could be a fairly large variable.

Also, I think we are also losing out by not passing the target or any other contextual information to the handler constructor. For example, if the target for the is the cache table then why would you also pass it to the functions?

handler('cache', $table)->get($cid, $table);

vs

handler('cache', $table)->get($cid);

I somewhat doubt that this array will become large. These handlers are used when there are changeable implementations of one given functionality. That should be quite rare outside of core and even core has only a few (cache, session, path, mail, http, password and come Tuesday, field storage). And most of these core ones (at least cache, session, field storage and path if aliases are used) are needed on every page request anyways.

And we pass around $table because there is no point in having a separate object for every target. That said, we currently do store a separate object for every target, so here is a patch which does not do that, which, I guess, saves memory in the default case compared to the previous patch which held a separate cache object for every target. It's still mandatory to pass in $table to every caching method because in the default case you wont get a target and in such a case one object needs to be able to handle everything. Note that for example field storage will pass around $field but the $target will be $field->type so it's just coincidence that for cache an argument and target is the same. I can imagine though some handler modules (esp for field storage) which are able to handle only specific targets and those can throw an exception in their constructor now because the constructor gets the target for specific targets and nothing for the default case.

Trying not to push this patch into killing a horde of kittens here but really, in the context of handlers, the goal of the clearing method should just be to clear. If you want to "clear all" (which only really clears 2 caches...) then IMO it should be a function that calls 2 handler calls. Its a special case, and there shouldn't be anything keeping the system from storing those 2 caches in different handlers. It seems like the goal of the handler methods should encompass very specific functionality only, not special cases.

I'm also not convinced that passing contextual information to the constructor isn't the right way and keeping individual objects isn't the right way, or even a way that will be required for some implementations. I have to concede that it could eat a lot of memory though.

I see no real difference with Crell's approach.

What I said in the other issue still stand:

• We actually don't need hook_handler() because we could extend the registry to store the information "this class implements the following interfaces"
• I don't believe we need a common factory function (ie. the handler()) function, because the different subsystem will have different needs:

drupal_cache($table, $cache_id)->get() // I should be able to choose a cache implementation by (table, cid), not only by table...
drupal_mail($recipient)->send($message) // I should be able to choose a cache implementation by recipient (for example by destination domain), for this I may want to implement a custom routing function, as in the call routing patch.
drupal_http($base_url)->get($path) // If we want to take advantage of HTTP/1.1 connection persistence, we need to route by $base_url, in order to reuse previous connexions to this server
drupal_user_authenticate($user)->authenticate($password) // I may have different user class (ie. LDAP vs. local users), with complex routing needs (ex. all users are authenticated with LDAP, except user 1)

I like this as a pattern, but I believe we don't actually need the common implementation. Let's agree on the general "handlers pattern" (ie. a strategy pattern based on interfaces, with a plain factory function specific to each subsystem), and convert each subsystem one by one, based on their specific needs.

@Damien I agree. I believe that is why Crell's patch doesn't actually include an implementation.

No really related to this issue but I agree with Crell that you're mistaken about the cid being part of the target. I think we can agree to discuss that on a different issue though.

I should clarify, I agree we shouldn't be arguing final implementation.

However there are several things that are quite different in these two patches. Most drastic is the storage of information and how the handlers interact with the system. And partially because of the later point and because of some design decisions , the basic implementation is somewhat important.

We need hook_handler() because we want to make it possible to write an UI to pick between handlers in a followup patch. We are fine with handler() because the wrapper functions will contain the logic to find out a useful target for the given slot. Right now the logic is target == table but for fields we will use handler('field_storage', $field->type), for drupal_http_request we will use handler('http', $base_url) and so on. We are not exposing handler() itself to end users. Maybe we should rename to _handler?

Further cleaning of caching is a followup issue.