Decide between events and OOP hooks

With perhaps the added thought that we already moved from hooks to events, so moving back might be a bit annoying to anyone who already converted their hook implementations.

I think this is a big argument to keep moving ahead in the direction we already established.

Unless there is a particular advantage or disadvantage to using events over OOP hooks I'd stick with what is there for a bit and see how the community shakes out (both other php projects and drupal itself). It seems like there's some waffling going on.

I think we should stick with events.

Events are fine. Hooks are fine for what they are, but events seem less hacky.

Well, let me submit the opposing viewpoint then: I think search_api should use OO hooks. Reasoning, in no particular order:

* Drupal Core has decided this is how we do things in Drupal land.

* search_api is a prominent project, and its codebase is read by many an aspiring developer, I think it ought to show the proper path.

* The ergonomics of OO hooks is, IMO, better.

* OO hooks is AFAIK based on events anyway.

Thanks a lot for weighing in on this, everyone! Good to get feedback on this decision.

It’s not a lot of voices so far, but seems there is a strong preference for sticking with events. I’m gonna let this open for a bit more and then mark as fixed. We are free to revisit this in case there are further developments.

@xen: I don’t think that OOP hooks using events internally is really an argument, since that’s immaterial to anyone using or defining them. It’s more an implementation detail and doesn’t make them any more in line with general PHP best practices.

@drunken monkey
> I don’t think that OOP hooks using events internally is really an argument, since that’s immaterial to anyone using or defining them.

It was more of a technical argument. But if that's the case (I'll admit to not have bothered looking into it yet), one ought to be able to use an event subscriber to "listen" for hooks. Not that I'd recommend it.

> general PHP best practices

Speaking of practices, one of the most important is "be consistent". If there are two ways to solve a problem, always pick the one that's already in use in the project. The Drupal project has chosen OO hooks over events, some might argue that they ignored said rule, but I don't think it was done without thought. And when core choses a way, contrib ought to follow in order to safeguard the consistency of the project as a whole, unless they can provide a convincing argument as to why this would be a bad thing.

This isn't about whether one is better than the other, it's a matter of doing things the Drupal way when you're in Drupal land. I much prefer Laravels interface naming, but when I make an interface in a Drupal module, I use Drupal naming convention.

Marking this as fixed with the decision of sticking with events for now.

Wow. I'm just going to chime in that @xen thoughtfully detailed an extremely valid reason to follow software platform/base convention and... @drunken monkey, you just...what, decided to completely ignore it?

Wait, let me actually break down what I'm seeing here further.

1. The question as to whether to adopt hooks over events originally came up in this Search API Autocomplete thread 📌 Convert all hooks to events Active .
2. Drunken Monkey, actually said "good point" and then took the initiative to open this thread, with the sole purpose to discuss...
3. @xen had the highest word count contributing to the discussion - and it's not fluff. As I said before it's well thought out and valid.
4. Drunken Monkey ignored valid points and marked as fixed with no reponse.

My issue here isn't with the decision or anything else. It's that time, consideration, and discussion was specifically solicited. And then it was almost categorically discounted and ignored. That's just rude. @drunken monkey, in the future when you take the initiative to open a ticket specifically asking for engagement, fulfill your absolutely basic, most minimum expected duties as the moderator and thoughtfully respond in kind. #welcometoopensource #opensource101

I prefer to stay with events as well. The reason is that third-party libs like solarium or others to integrate search backends are using events, based on a PSR standard.
Now it is possible to bundle search related customizations that build one feature together in one event subscriber that subscribes to events of serach_api, serach_api_solr, solarium and facets.

@mkalkbrenner
And you wouldn't be able to bundle it all together in one hooks class, if the related modules did it the Drupal way?

@w01f: I did thank everyone for contributing their opinions and I am also thankful to xen for his contradictory one and the clear arguments he provided. However, they were obviously not enough to sway any of the others to change their vote so it’s a pretty clear 4-1 decision.
I explicitly announced in #7 what I would do:

It’s not a lot of voices so far, but seems there is a strong preference for sticking with events. I’m gonna let this open for a bit more and then mark as fixed.

It was of course xen’s right to try again to persuade people of his standpoint, but if no-one was engaging in the debate anymore it didn’t seem cause for keeping this issue open any longer. And as I had just posed the question, not voiced an opinion either way it wouldn’t have made much sense for me to argue with xen just for the sake of it.

I might have explained all that in #9, though, you’re probably right, so I’m sorry if that came of as rude.

@drunken-monkey, I could have been less sarcastic in my response as well. Thanks for adding your reasoning.

@drunken monkey
> no-one was engaging in the debate anymore

Well, apparently it wasn't a discussion, but a vote. I'm still waiting for someone to explain to me why Search API is so special that it needs to deviate from what is now The Drupal Way, apart from "well, we've already done events" and "everybody else is doing it".

I can't imagine that anyone thinks that having two different ways to accomplish the same thing spread over the contrib ecosystem is a particular good thing.

But if nobody wants to discuss it. *shrugh*

I went the "events way" in all the contrib modules I'm involved in. And a s far as I know, Core still does events as well.
And other big contrib modules like commerce are using events as well.
I don't think that one thing is right and the other is not. And there's not the one drupal way.
My understanding is that hooks get an OOP replacement. But it is totally valid to use Events.
BTW I would have preferred to replace hooks in core by events and closer following a PSR standard instead of introducing something new that is drupal-specific.

Automatically closed - issue fixed for 2 weeks with no activity.