Jump to:
| Project: | Drupal Queue |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
Hi
I've been using the Drupal Queue module and it's great. However I don't use the Autoload module, so when I have to use the queue functionality, I have to do a drupal_queue_include() first.
Performance is of course important, but I can't help wonder, if all this isn't just micro optimization at the expense of a more cumbersome setup and API.
The include has been put into drupal_queue_include() because module_load_include() is slow. But ... just how slow is it? Does it really make a difference, or is it in fact just micro optimization?
Also to avoid module_load_include() you could just embed the class directly into the drupal_queue.module file or do an include(__FILE__ . '/drupal_queue.inc') in the global scope of drupal_queue.module... Or is that bad practice?
Then there is of course the question regarding module_invoke_all('drupal_queue_load_classes') which might need to be put into hook_init(). But then it's perhaps too late? Without having tested or investigated it, I actually suspect the module_invoke_all('drupal_queue_load_classes') won't work if queue functionality is used in hook_boot(). Don't know if this is the case for Drupal 7 also.
I don't necessarily have a solution or say that the current implementation is wrong, I'm just raising the issue, to get a debate whether there's a simple solution the actual problem which is: "I shouldn't need to call drupal_queue_include() when I wan't to use queueing".
Anyways, these are just thought. I could just install the Autoload module, but then my modules have to depend on Autoload for no "apparent" reason. Perhaps depending on the Autoload module could be the answer, to ensure same API as Drupal 7 #650814: Use autoload module for classes
Comments
#1
Well I guess I'll just close this ticket then ...