Advertisement:

Author Topic: Rethinking hooks - thoughts from other places  (Read 605 times)

Offline Suki

  • Kaizoku Jotei
  • Developer
  • SMF Super Hero
  • *
  • Posts: 15,476
  • Oh, wouldn't it be great if I *was* crazy?
    • MissAllSunday on GitHub
    • SMF mods
Re: Rethinking hooks - thoughts from other places
« Reply #20 on: Yesterday at 11:31:38 AM »
My experience with observables/ events/listeners is that they quickly become too cumbersome (Symfony and Laravel) and invassive. Symfony for example has too much boilerplate code and the way you need to declare your listener isn't always the best experience. I like SMF's hook system because of its simplicity, its raw, straight to the point code.

 I agree hooks needs to be separated and categorized and that not all categories will really be called "hooks" or even resemble them.

Indeed I thought about giving hooks a way to set their priority, heck, even separate them from the settings table to avoid having an active hook while uninstalling it for example

For 3.0 I want to port some of that hook simplicity, to be able to execute whatever you want on a certain point in the code lifecycle does have its charm, however, that level of liberty was only achievable by abusing global scope, which isn't something I plan to continue doing.

Indeed routing needs to be on its own, haven't decided how exactly tackle that but certainly a way to extend/listen the route system needs to happen.  The rest?  I think the question of what we will do will become clear once we have set a code structure and architecture.  I'm not closed to have more than one system or even more than one way to declare/use a system.


I just used Notepad++ to do a quick search for "function __construct(" and it seems like the only OOP code is 3rd party code. Why hasn't OOP been used for 2.1?

Because 2.1 wasn't meant to be re-write.  2.1 supports mods been completely OOP.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 71,228
    • StoryBB/StoryBB on GitHub
Re: Rethinking hooks - thoughts from other places
« Reply #21 on: Yesterday at 11:46:23 AM »
I don’t disagree that it can very quickly escalate - the boilerplate I deal with for listeners in Totara is more effort than the type of boilerplate I suggest here (and am using), though I don’t have any recent Laravel or Symfony experience. Priorities are a really nice to have feature and if you’re already thinking of overhauling it in future, I’d definitely suggest adding it.

Though I think that the emitter is not exactly more code and the data carrier (something SMF doesn’t exactly have, it just passes everything directly, which has the side effect of listeners having to remember to declare what is a reference)... well, the data carrier by being an actual object has the advantage that it becomes pretty self documenting and easy to look up later.

You don’t have to explicitly remove them from the settings table to get what you’re looking to achieve, you just have to not do added-to-list-of-hooks as a default. If you add them at run time rather than install time, this whole problem is entirely solveable.

Routing is a thing I’m working on, and every framework seems to do it differently, just because they all have slightly different quirks, mostly around how far the separation between slug and id goes, e.g. some of them seem to suggest /route/slug/id versus something like XenForo’s /route/slug.id/ style approach.

I just took the view that hooks really should be for event emitting or in-flight changing, and that routing isn’t really something that should have a generic hook.

But I’m not trying to suggest what SMF 3 should or should not do, merely this is what I’m doing and it might be an interesting thing to look at as it might help guide thinking towards or away from certain things. I definitely think the current approach has issues, these are the ones I see and what I want to do about it inside my bubble. It may happen that it works out well, it may happen that I have drastically misjudged it, especially as I’m going to end up being the principle mod author.

I also have to realise that I have a litany of things I’d love to do but even time to actually do them...
Don’t try to tell me that some power can corrupt a person. You haven’t had enough to know what it’s like.

No good deed goes unpunished / No act of charity goes unresented.

Offline SpacePhoenix

  • Semi-Newbie
  • *
  • Posts: 80
Re: Rethinking hooks - thoughts from other places
« Reply #22 on: Yesterday at 12:12:38 PM »

Because 2.1 wasn't meant to be re-write.  2.1 supports mods been completely OOP.

Was 2.1 basically meant to be just fixing things that got broken with PHP version 7.0 and newer?

Online Aleksi "Lex" Kilpinen

  • A Peculiar Finn
  • Lead Support Specialist
  • SMF Super Hero
  • *
  • Posts: 18,452
  • Gender: Male
  • Don't worry, I'm n00b friendly
    • Aleksi.Kilpinen on Facebook
    • LexArma on GitHub
    • aleksi-kilpinen on LinkedIn
    • There's No Place Like 127.0.0.1
Re: Rethinking hooks - thoughts from other places
« Reply #23 on: Yesterday at 12:15:53 PM »

Because 2.1 wasn't meant to be re-write.  2.1 supports mods been completely OOP.

Was 2.1 basically meant to be just fixing things that got broken with PHP version 7.0 and newer?
No, it's supposed to be a .1 release.
A Finnish Support Specialist
 Happily running multiple SMF 2.0 installations.
  Fooling around with an i7 990X @ 3,47Ghz / 12Gb / Win 10 x64 / 3840x2160


How you can help SMF

"Before you allow people access to your forum, especially in an administrative position, you must be aware that that person can seriously damage your forum.
 Therefore, you should only allow people that you trust, implicitly, to have such access." -Douglas

Offline Suki

  • Kaizoku Jotei
  • Developer
  • SMF Super Hero
  • *
  • Posts: 15,476
  • Oh, wouldn't it be great if I *was* crazy?
    • MissAllSunday on GitHub
    • SMF mods
Re: Rethinking hooks - thoughts from other places
« Reply #24 on: Yesterday at 12:22:04 PM »
I don’t disagree that it can very quickly escalate - the boilerplate I deal with for listeners in Totara is more effort than the type of boilerplate I suggest here (and am using), though I don’t have any recent Laravel or Symfony experience. Priorities are a really nice to have feature and if you’re already thinking of overhauling it in future, I’d definitely suggest adding it.

Though I think that the emitter is not exactly more code and the data carrier (something SMF doesn’t exactly have, it just passes everything directly, which has the side effect of listeners having to remember to declare what is a reference)... well, the data carrier by being an actual object has the advantage that it becomes pretty self documenting and easy to look up later.

You don’t have to explicitly remove them from the settings table to get what you’re looking to achieve, you just have to not do added-to-list-of-hooks as a default. If you add them at run time rather than install time, this whole problem is entirely solveable.

Routing is a thing I’m working on, and every framework seems to do it differently, just because they all have slightly different quirks, mostly around how far the separation between slug and id goes, e.g. some of them seem to suggest /route/slug/id versus something like XenForo’s /route/slug.id/ style approach.

I just took the view that hooks really should be for event emitting or in-flight changing, and that routing isn’t really something that should have a generic hook.

But I’m not trying to suggest what SMF 3 should or should not do, merely this is what I’m doing and it might be an interesting thing to look at as it might help guide thinking towards or away from certain things. I definitely think the current approach has issues, these are the ones I see and what I want to do about it inside my bubble. It may happen that it works out well, it may happen that I have drastically misjudged it, especially as I’m going to end up being the principle mod author.

I also have to realise that I have a litany of things I’d love to do but even time to actually do them...



 I agree with you.  (shock!) :D

And its basically what I want to do too. The data carrier is an interesting concept and its what I had in mind. Just need to find a balance between been really useful and been bloated. This is why having more than one way to listen/emit could be used but then again having more than one means more stuff to test, overlapping functionality and that kind of fun stuff.

Routing, that's where my headaches start. I want SMF to be as framework agnostic as possible (use but not depend), this means two things, use X framework's routing stuff or write our own, both has its pros and cons and that's where I'm stumbled.


I have a bazillion ideas for 3.0, some of them are written down, some others are just floating on my head and indeed time constraints are a pain in the posterior.
Disclaimer: unless otherwise stated, all my posts are personal and does not represent any views or opinions held by Simple Machines.

Look at them. They're just asking for it. Maybe the human race deserves to be wiped out.