Evil "eval()" dead?
- Thread starter AlexT
- Start date
R
ragtek
Guest
I think Alex knows this, but as he's saying => "eval is evil"
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.
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.
GameR
Active member
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
}
}
Jerry
Well-known member
Now I wonder if there was any origional vB developer who had anything to do with HipHop .....
R
ragtek
Guest
Now I wonder if there was any origional vB developer who had anything to do with HipHop .....
Hehe, thought the same
pegasus
Well-known member
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)
"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
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.
Regarding HipHop, I'll throw it through when I get a hands on a copy.
pegasus
Well-known member
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.
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.
Similar threads
- Question
