• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Evil "eval()" dead?

Cezz

Well-known member
#5
This would be great to know actually, would really show for the quality of the code if in building this from the ground up eval() was avoided...

Though I would be happy either way as long as it works it would still be awesome.
 

Mike

XenForo developer
Staff member
#7
eval() is still used for templates currently. The template syntax is very rich, so it compiles down to native PHP code as you might expect and these are loaded from the DB on demand. There is code in our template class to read them from the file system, though this functionality hasn't been completed yet; at the least, it's been considered since the beginning as this would allow byte code caching (APC).

Plugins (well, "code event listeners") don't use eval. You specify a class+method and that is (auto)loaded and your code is run. The listener is given a specific set of arguments, similar to MediaWiki. This actually makes it documentable, and allows more backwards compatibility or at least documentation of potential issues.

Eval() not withstanding, I'm not sure how HipHop would handle the code. We haven't run it through the static analyzer yet, though it's on the cards. I'm not sure how it would handle including template files, and you would certainly have to recompile if you edited a template.
 

Enigma

Well-known member
#9
Plugins (well, "code event listeners") don't use eval. You specify a class+method and that is (auto)loaded and your code is run. The listener is given a specific set of arguments, similar to MediaWiki. This actually makes it documentable, and allows more backwards compatibility or at least documentation of potential issues.
Thanks Mike. That kind of answers my question from over here.
 

calorie

Active member
#10
There have been times that I've wanted to "return" while in an "eval" but cannot because, well, it is an "eval" so it would be nice to have that restriction gone.
 

GameR

Active member
#11
… Plugins (well, "code event listeners") don't use eval. You specify a class+method and that is (auto)loaded and your code is run. The listener is given a specific set of arguments, similar to MediaWiki. This actually makes it documentable, and allows more backwards compatibility or at least documentation of potential issues. …
I worked a long time as trainee by WoltLab, and there the event class structure is this:
PHP:
class MyEventClass {
public function execute($eventName, $eventClass, $eventObj) {
// ... my code
}
}
Is the xenForo event system comparable to this class-structure?
 

Mike

XenForo developer
Staff member
#12
Simpler really. You don't have to have an event object with an execute() method; you just tell it what the callback method is and it will call it statically.
 

pegasus

Well-known member
#17
When asked if I would be porting any of my mods from vB to XF, I had this to say:
"It ... depends if the plugin system that they implement offers at least the same amount of customization that vB3's did. While eval() has its extra overhead, it does allow you to modify anything in the current scope, which listener classes+methods don't really allow, unless they were written to emulate eval, in which case, I don't know if any performance is really saved... The best alternative I think is a file-based plugin system, where instead of eval() it just uses include() based on a registry of files, similar to how scheduled tasks are added in vB." (view original post)
 

Scott

Active member
#18
The hook based callback system is better since you have much stronger control over what each plugin location should and can do. You can document the parameters and the return value that the callback can do etc.

Regarding HipHop, I'll throw it through when I get a hands on a copy.
 

pegasus

Well-known member
#20
Technically, even if you make your code completely class-oriented, it is still going to be partly procedural, that's just the nature of pretty much every computer language I can think of.

In terms of some mistakes vB 4 has made in this arena, if you start making class methods or properties protected or private, you limit customization possibilities. As for plugins, this will depend on if the "classified" variables are made available to the listener. If it's just one or two variables that we are "allowed" to modify, this limits customization. If certain items are customizable also depends on how certain objects are instantiated, and if we have multiple instances, how we know which instance is for what. It all depends on the implementation, and we don't know how XF's system is implemented yet. I'm sure everyone would prefer maximal customization possibilities.