« Mods - no not *that* question!
Plugin hooks

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin hooks
« Reply #60, on March 30th, 2011, 05:32 PM »
So... Dragooon, what do you think we could do, either by adopting ToxG or by using a purely PHP solution?

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Plugin hooks
« Reply #61, on March 30th, 2011, 07:10 PM »
Quote from Nao/Gilles on March 30th, 2011, 05:32 PM
So... Dragooon, what do you think we could do, either by adopting ToxG or by using a purely PHP solution?
As in what advantage it would bear or how should it be adopted? If you're looking for advantages then they are(From top of my head) :

- A mod can modify the output without actually altering the templates, by proper implementation of template one gets a powerful template hook system free. Something which is virtually impossible in a pure PHP scenario regardless of how you look at it.
- The templates can be systematically broken down into less confusing pieces, for example(This is taken from vBulletin), a user's online list item would be an individual template. A single child board listing would be its own individual template, this gives a lot of power to not only themers but also moders while maintain sanity.
- No PHP-fu in between templates(If you enforce TOX-G that is). Keeps logic and template separate
- One can code up a strong admin panel for modifying templates which can be easy for the end-user.
- It is not slower than pure PHP by more than 4-5%.

Advantages of PHP over TOX-G :
- Unlimited possibility of syntax.
- Very marginally faster
- Already in place, no need to bang heads converting code
The way it's meant to be

texasman1979

  • Posts: 99
Re: Plugin hooks
« Reply #62, on March 31st, 2011, 12:01 AM »Last edited on April 7th, 2011, 04:56 AM by texasman1979
...
LOGIC is a FOUR letter word! :)

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin hooks
« Reply #63, on March 31st, 2011, 12:16 AM »
Are you in trouble with the punctuation police? :P
Quote from texasman1979 on March 31st, 2011, 12:01 AM
2 things id like to comment on: integration hook system and template system. Integration hook system. Think of a switch statement. You have a list of conditions and a default. The very nature of a switch is faster than a nested if.
Well, if there are not a lot of different possibilities, the if is faster. Plus, I think it's more readable.
Quote
Make a small c prog and look at the machine code/object code.
Does a Pascal program count?
Quote
Instead of waiting till you get there to ask and see if there is a hook, already know when you get there. The theory is in my head but it is difficult to express in words. Each action has a path. Find out if that action has a hook then contenue through the action then knowing the path needed to go. Make hooks one of the first things done when an action is requested by way of a switch.
Implementing hooks is not easy in terms of performance. However, it's not realistic to optimize this, especially at this point. Alpha status should be there for implementation new functions. We can start optimizing for speed when in beta. And even then, I'm not sure that many 'wasted' hooks would account for more than a few milliseconds. You have an array with all possible hooks in memory -- any calls to call_hook() (well, that's the name of the function in Wedge) will be negligible really.
Quote
Use switches in every possible time, instead of ifs.
I don't know where you got that from... (And there are so many ways to optimize common PHP code. This particular example is not that good really.)
Anyway, if you're interested in micro-optimizations, you should follow SMF 2.1's development instead. Apparently they're very keen on changing "==" to "===" everywhere.
Quote
Dont use memory/hd unless there is no other way to do it. Mysql and apache are already using resourses, reuse those in every conceivable fashion instead of drawing more resources. If you dont need a particular setting, dont load it. Even comments generate more lines of code cause it has to determine if it is a comment or not.
That's what opcode caching is for.
And *any* webmaster that has a critical need for performance, will definitely install an opcode cache. At that point, who cares whether we use ifs or switches? It's all going to be the same, as it'll be precompiled...

On the contrary, comments are faster. Not because the code executes faster -- but because it's faster to understand what the code does, and thus, to optimize it.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin hooks
« Reply #64, on March 31st, 2011, 12:19 AM »
Quote
Think of a switch statement. You have a list of conditions and a default. The very nature of a switch is faster than a nested if. Make a small c prog and look at the machine code/object code.
Ever done that? That's rather enlightening, but different languages handle switch vs if/nested if in different ways, some run to linear time with the increase of options, some to logarithmic time. PHP is basically a shell around C, so it will do virtually what C does for something like that, which means that on modern systems... if you have 4+ options, or 2+ if you have cases that fall through to each other, switch is usually faster. Depends on the circumstances.
Quote
Find out if that action has a hook then contenue through the action then knowing the path needed to go.
SMF, Subs.php, see call_integration_hook().
Quote
Make hooks one of the first things done when an action is requested by way of a switch.
SMF actions (and ours) are not controlled by a switch but a local scope hash table. (Might be global scoped in Wedge, but it's certainly a memory hash table initialised directly from PHP code)
Quote
Template system. 100% static.
Way to go on screwing up customisation, not to mention dynamic content.
Quote
Only echo predefined values. Gives modders a way of changing the template, without changing the template.
Not possible with 100% static.
Quote
Mysql storable, cacheable.
Depends on the circumstances. Also note that not all hosts are properly configured for caching, not all hosts even provide services like memcached, and often have MySQL's query buffer set way too low to be useful to the point where you might as well explicitly push queries without going to the buffer in the first place, would actually be faster on the majority of installations.
Quote
Different templates for different days, so to speak
There are already hundreds of templates in SMF, and we have already added more subtemplates and will be breaking the existing ones down.
Quote
Use switches in every possible time, instead of ifs.
No.
Quote
Dont use memory/hd unless there is no other way to do it.
Eh? What do you think memcached does, exactly?
Quote
Mysql and apache are already using resourses, reuse those in every conceivable fashion instead of drawing more resources.
Step 1, don't use Apache if you're even remotely concerned about performance.
Quote
If you dont need a particular setting, dont load it.
Dear god no. The time taken to figure out whether a setting should be loaded invariably outweighs the actual time to load that setting.
Quote
Even comments generate more lines of code cause it has to determine if it is a comment or not.
If performance is your goal, you should be using APC which makes that point redundant.
Quote
What im saying is, preprocess, process, display using as few steps as possible.
So let's throw out any sense of customisation then?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

texasman1979

  • Posts: 99
Re: Plugin hooks
« Reply #65, on March 31st, 2011, 03:04 AM »Last edited on April 7th, 2011, 04:55 AM by texasman1979
...

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin hooks
« Reply #66, on March 31st, 2011, 08:39 AM »
Dragooon, I thought you said you had a PHP template hook in mind?

Pete, looks like we replied at the same time ;)

texasman, line-breaks are good but you really should consider using the spell-check function in your browser, eh... And capitals, too! Right now I need a break! tl:dr :^^;:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin hooks
« Reply #67, on March 31st, 2011, 09:29 AM »
I was going to write up a rebuttal to each of the points being made here, but I'll sum it up in two sentences.

Firstly, did it occur to anyone reading this debate that the above points *hadn't* gone through either or both of our minds?

Secondly, I see a lot of talk about being the best it can be and doing it a certain way which certainly sounds grand - but wake me up when you actually have some idea of how you think it should be implemented, because I'm telling you from a practical POV, it really isn't as grand as that in reality, reality just doesn't work that way.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Plugin hooks
« Reply #68, on March 31st, 2011, 09:40 AM »
Quote from Nao/Gilles on March 31st, 2011, 08:39 AM
Dragooon, I thought you said you had a PHP template hook in mind?
The first thing I would not do is that. PHP template hook are very difficult to achieve and are a sad sad practice.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin hooks
« Reply #69, on March 31st, 2011, 03:41 PM »
texasman, you can have a signature in this forum, AFAIK.

Regarding your multi-threaded switch modifiability sensors... Wow, what are you on? You've got to share now!
Same as Pete for the rest. You are, after all, free to create your own fork of SMF2 at this point.

Dragooon, hooks aren't a sad practice. They're actually one of the most practical solutions to the problem of customizability... The only point is that we have to be careful how fast execution of empty points is.
Basically, in Wedge, it's as fast as en empty() test. At this rate, we could very well set hooks every other line in the code without it becoming significantly slower. (We will, instead, stick to adding hooks where it seems reasonable enough. We will probably add more hooks during the alpha and beta sessions at the request of modders.)
Now, when it comes to templates, we can do it in two different ways: either regular hooks inside the functions (either at the beginning, or at the end, or both), that's for replacing entire functions, or detecting frequently modified elements and replacing them with generic blocks. (The things like <we:cat> that I implemented a couple of months ago.)

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Plugin hooks
« Reply #70, on March 31st, 2011, 05:31 PM »
Quote from Nao/Gilles on March 31st, 2011, 03:41 PM
Dragooon, hooks aren't a sad practice. They're actually one of the most practical solutions to the problem of customizability... The only point is that we have to be careful how fast execution of empty points is.
Basically, in Wedge, it's as fast as en empty() test. At this rate, we could very well set hooks every other line in the code without it becoming significantly slower. (We will, instead, stick to adding hooks where it seems reasonable enough. We will probably add more hooks during the alpha and beta sessions at the request of modders.)
TBH manually positioning every hook in every bit of template is a very impractical practice, it may seem workable in theory but I don't see it actually working out. Hooks in actual workflow is a lot more sensible and practical thing.
Quote from Bloc on March 31st, 2011, 05:22 PM
I do hope PHP in Wedge's templates isn't taken out, since thats whats currently keeps my interest lmao. :)(not that I expect Wedge to stop because of me though ;) )

I have spoken in favor of TOXG before, but I just don't see the kind of freedom with it that PHP templates providest, sorry to say. If anything it seems more cumbersome to MIMIC using PHP than just use PHP right away.. The mod/theme problem is VERY well solved by it though..but if there won't be a problem why use it then?


As for templates not being allowed to use PHP, because its "dangerous" or "not to be trusted"..wake up I'd say. One of most widespread scripts around use PHP in their templates(and not only WP either) and they haven't wreaked havoc yet! I would imagine that for those that seldom make templates or just change a color here and there, the idea of using nice formatted HTML that fit just right into Dreamweaver, is a must-have.

For everyone else though, the benefits are very clear. And last I checked it was the actual CONTENT that was considered risky allowing too much freedom for - not the design.
The thing is, Tox-G adds a lot of possibilities otherwise which I consider to be quite hard doing with pure PHP without actually limiting a designer. I haven't encountered a thing that I can't do with pure TOX-G. But to each it's own, PHP got its own advantages. One of my main motives of  advocating TOX-G is because of it's hookable nature, I am not against PHP, it's just that a template engine is a better option and TOX-G seems to be the best one at them for a forum software.
Re: Plugin hooks
« Reply #71, on March 31st, 2011, 07:23 PM »
Quote from Bloc on March 31st, 2011, 06:43 PM
I like my car to go from spot 1 to 2 without breaking down and being reasonably fast. I don't care if it can actually fly because theres no allowed areospace for it to fly in anyway...

TOXG was made by Unknown to solve a specific problem. If said problem doesn't exist anymore(or will not exist)...why have that car with wings that you can't use? It would actually require more resources(=fuel) because of the added "feature".

Just saying. :)
Posted: March 31st, 2011, 06:40 PM

oh, and talking of doing stuff in tempaltes which isn't possible otherwise..there just isn't many(=none) around that actually utilize the power of said PHP we have now - in SMF - so I won't hold my breath that TOXG will be any different in that respect.
I don't think that problem was ever solved. Mods still need to modify the template to alter that output, unless I am mistaken.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin hooks
« Reply #72, on March 31st, 2011, 07:28 PM »
Mods can alter the content that's going *into* the template with out editing the hook itself. But that's only any good provided that you're providing it more of the same, or internally reformatting it for whatever reason.

If you need to extend the template in any way, i.e. do something other than for which it was designed in any way that can't be done through the exact markup provided, you either have to design the template to feed more from the source or allow it to be modified.

The former example, to 'feed more from the source', I'm thinking you'd make more use of stuff like GenericList for it; in order to make a given table more dynamic in terms of columns (new rows is easy), you'd need to move everything out of hardcoding the table structure.

The latter example is where you want to do inline some new content into the template.

texasman1979

  • Posts: 99
Re: Plugin hooks
« Reply #73, on April 1st, 2011, 03:39 AM »Last edited on April 7th, 2011, 04:55 AM by texasman1979
...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin hooks
« Reply #74, on April 1st, 2011, 08:59 AM »
Considering that the only initialisation of hooks is simply an entry that goes into $modSettings, which is automatically cached, and even if it wasn't, it's subject to the fastest possible query it could be - and that on a performance system it's going to be loaded from memory via memcache, I see no reason to convolute the entire process for tests that in practice will not make it any faster in the majority of cases, and I'm not compromising general performance for outliers.
« Mods - no not *that* question!