We actually use very little of the Zend Framework - the vast majority of the code that runs XenForo is bespoke. The plugin system in particular is entirely unique to XenForo.
To answer the question though, yes, collisions are far less likely and better handled by XenForo than by the vBulletin plugin system due to the fact that XenForo's plugin system has strict control over the data exposed to each callback function, whereas vBulletin's hooks for the most part exist in global scope, allowing them to modify just about anything at will. While the approach we took when we wrote vBulletin's hook/plugin system allows for great flexibility, it has the caveat that it's virtually impossible to avoid collisions, or to ensure backward compatibility through newer versions. Hence why we did it differently for XenForo.
Kier and Mike have done a really amazing job in creating the underlying framework. The framework upon which this Forum application sits. The clear logical separation of different application parts goes a long way in ensuring you can elegantly reuse something without resorting to hacks.
vB doesn't keep mods separate? I actually think, with vBulletin, it was quite the opposite. XenForo provides a level playing field for all the Addons; and better integration with the core components. So there's less hacking needed to just "get" things to work. The result? Less chance of addons stepping on each others' toes.
There are well defined interfaces for handling things such as attachments, likes, search, alerts, content moderation, news feeds, etc. Addons can implement each of these features without interfering with other addons or the core itself.
I was actually just responding to Miko about his work... and XF being the foundation for his work, I have never seen such innovative or creative work able to be performed on other forum platforms as I'm seeing in development and "what's to come" developments from people surrounding XF.
If the add-on coder have no idea what he's doing (like me some time ago) it will crash all the other add-ons running on this event*scnr*
This couldn't happen in vb, because you hadn't to run the parent action...
If something went wrong, you got an error, now with XF, it throws no error if you don't run the parent method.
In some cases you'll never realize that the other listeners weren't called
Yeah... with my RecentThreads block in XenPorta. Several other mods are expanding the core functionality of the Thread model, so when I tried to expand the core functionality the same way, I started getting duplication errors. I fixed this by instead of expanding on the core model, I simply used the existing functions and put it together in my own thread builder.
Well it is used in the US, though I admit it is not often...just it's not in a custom tailored clothing sense...it is used as the past tense of bespeak which can literally mean to speak to, respond to, to address or to be accounted for. So in the context it was used (I believe) it would not be the same in both places. But funny thing is the present tense of the word can mean to request ahead of time or to engage in advance. I just found that to be a bit of awesome right there given the OP. LOL