Support for pecl-event extension custom namespacing.

[Donatello-za]

A few weeks ago I ran into a class name conflict between the pecl-event extension's Event class and a class with the same name in the popular Laravel and Lumen frameworks.

I'm going to keep my explanation short but you can read more about it here:
Basically, if the pecl-event extension is installed, Laravel/Lumen's php artistan command fails saying that the Event class is already declared.

This is a pain as the only way to get around the problem is to disable the extension when one wants to use the php artisan command line tool, which is very often. This is also a potential production nightmare.

As a result the owner of the pecl-event extension built a configuration flag that can be used to compile the extension with a custom namespace (by default it has none, hence the naming conflict). For example, one can use: ./configure --with-event-core --with-event-extra --with-event-ns='Osmanov'. Note that Osmanov is a reference to the owners repository name.

In order to use the pecl-event extension with the compiled namespace I implemented a class that replicated React\EventLoop\ExtEventLoop but used the Osmanov\ namespace, e.g.:

use Osmanov\Event;
use Osmanov\EventBase;
use Osmanov\EventConfig as EventBaseConfig;

use React\EventLoop\LoopInterface;
use React\EventLoop\Tick\FutureTickQueue;
use React\EventLoop\Tick\NextTickQueue;
use React\EventLoop\Timer\Timer;
use React\EventLoop\Timer\TimerInterface;
use SplObjectStorage;

/**
 * An ext-event based event-loop.
 */
class OsmanovEventLoop implements LoopInterface
{
.
.
.

I then also implemented my own event loop Factory that also looks for the availability of the class:

    public static function create()
    {
        // @codeCoverageIgnoreStart
        if (function_exists('event_base_new')) {
            return new LibEventLoop();
        } elseif (class_exists('libev\EventLoop', false)) {
            return new LibEvLoop;
        } elseif (class_exists('Osmanov\EventBase', false)) {
            return new OsmanovEventLoop;
        } elseif (class_exists('EventBase', false)) {
            return new ExtEventLoop;
        }

        return new StreamSelectLoop();
        // @codeCoverageIgnoreEnd
    }

For now this is Ok for me except for the fact that I will always have to sync my version of the EventLoop class with any future updates to ReactPHP's event loop changes. Is there a possibility that we can in the future add this implementation as another "standard" option for the choice of event loops? I am of course willing to fork and doing a pull request if you think this is a feasible solution to the problem.

[WyriHaximus]

Hey @Donatello-za thanks for raising this issue with us. Personally I'm a bit conflicted because userland code should shouldn't declare classes in the global namespace, but also understand you're caught between two projects you have very little influence on. What I would propose is that you create a PR implementing this so we can discus and work it out.

[Donatello-za]

Hi, thanks for your response. I completely understand your argument and I'm still considering what the best solution for this issue would be myself. If I can't come up with any alternatives I will create a PR as you suggested and we can go from there.

[tux-rampage]

This will become a maintenance nightmare in React.

This is clearly a bug/design fail in Laravel/Lumen and should be addressed there instead of all libraries that may utilize ext-event. It even gives me shivers that the ext-event added such an awful feature as a workaround.

Edit: Do you have an option to switch from ext-event to another nbio scheduler like ext-ev?

[WyriHaximus]

Would recommend ext-uv at this point as released in v1.1.0.

[tux-rampage]

@WyriHaximus Even though ext-uv is highly experimental?

[WyriHaximus]

@tux-rampage yes, I don't have any issues running it in production

[clue]

This is kind of an old issue and hasn't seen any updates in a while, so I'll assume this has been resolved in a meantime and will close this for now, please feel free to report back otherwise 👍

This ticket discussed several options, e.g. using a different event loop or building a custom implementation using your specific namespace (non-portable).