Using methods directly instead of eval, is this approach better?

[Engr. Adiktuzmiko]

So, there are people telling us to avoid using evals because they are slow... One suggestion was to use Procs, but I don't like them or well, I can't understand them to a usable level. So I have made this alternative to using evals to run user defined things (which is much abundant to my extension scripts for example).

module ADIK  module LANTHANUM_BATTLE    module ENEMY_AS            def self.action_normal(user)        #Do things here      end       def self.action_mage(user)        #Do things here      end       #add more methods as necessary            TAG = /<enemy_as.*)>/          end  endend $dactb[:enemy_as] = ADIK::LANTHANUM_BATTLE::ENEMY_AS  class Scene_LanthanumBattle   alias set_up_enemy_command_as set_up_enemy_command  def set_up_enemy_command(user)      sym = $1.to_sym if user.note =~ $dactb[:enemy_as]::TAG    return $dactb[:enemy_as].method(sym).call(user) unless sym.nil?    return set_up_enemy_command_as(user)  end    end  
So now, you're running methods directly rather than using eval

then on the notebox, you'd just put something like

<enemy_as:action_normal>

instead of putting what action_normal would be doing inside of the notebox then using eval on it.

So, is it better than using eval?

 

[Shaz]

Meh - what is "slow"? Depends what the eval is and how often it's running. As the developer, you have control over that.


I would have a lot of other things I would do to speed the game up before I'd start worrying about how many milliseconds an eval is going to take to run

 

[Matchitza]

Meh - what is "slow"? Depends what the eval is and how often it's running. As the developer, you have control over that.

Yep... Depends what the eval is how often it's running... @Shaz is right, you have control over that  BD   BD

 

[TheoAllen]

I personally more worried on draw pixel / refresh per frame than eval per frame.

Also, it you ask if that's better, in terms of speed, yes better. In terms of friendly config, depends.

 

[Balrogic]

Wouldn't it be a little easier to read if you did it this way? You'll also avoid unpleasant errors if the user types the method name incorrectly or just doesn't like the behavior they made and deletes the method entirely. No need to clean up artifacts in note tags now, unless they want to change it to something else. http://ruby-doc.org/core-1.9.2/Object.html#method-i-send - Link to doc on send, respond_to? is described right above it.

$dactb[:enemy_as].send sym, user if $dactb[:enemy_as].respond_to?(sym)As for whether or not it's worth it, I just got a performance boost on a rather demanding test by moving a couple hundred evals per frame at the peak of the test into a method. Wasn't as much of an improvement as I got by removing a very busy puts statement from the method which in turn wasn't as much as I got by fixing a bug that made events rapidly spin in place under certain conditions (10 fps, here I come!) but it was definitely noticeable to me. Even with a fairly powerful CPU that can apparently handle 250 events marching across a map with simplistic pathfinding at 60 FPS now that I optimized my code a bit. I think I can squeeze a little more performance out of it yet. I do think it's worth figuring out how to get away from eval, sometimes you want to make something that's a little crazy and 2-3 FPS here and there can add up.

Also, it seems easier to configure a method one time instead of having to configure it every time you want to use it across your entire project. I can't see why it would be more difficult to configure the way it's posted at the top.

 

[TheoAllen]

Wouldn't it be a little easier to read if you did it this way? You'll also avoid unpleasant errors if the user types the method name incorrectly or just doesn't like the behavior they made and deletes the method entirely. No need to clean up artifacts in note tags now, unless they want to change it to something else.

Since it's a part of user config, the user should know what's the error instead of "why it doesn't work?" and realized that they did a silly stuff.

 

[Balrogic]

In which case you could stick something like this in the method.

puts "Warning! #{sym} is not a valid method name." unless $dactb[:enemy_as].respond_to?(sym)Now you've given a warning instead of an exception and subsequent crash to desktop.

 

[TheoAllen]

That would be better. I did the same thing in my script.

 

[Tsukihime]

Since it's a part of user config, the user should know what's the error instead of "why it doesn't work?" and realized that they did a silly stuff.

No, user config just means they are allowed to enter their own input. It doesn't mean they are expected to understand how to debug your scripts as a result of them entering something unexpected.


Especially if the script just crashes with no useful information.


Something simple like what balrogic has provided would help, but even then there's no expectation that a user should understand that it means for a method to not be a "valid name".

 

[TheoAllen]

No, user config just means they are allowed to enter their own input. It doesn't mean they are expected to understand how to debug your scripts as a result of them entering something unexpected.

They're not expected to understand, but they're expected to know, instead of just don't work.

 

[Tsukihime]

They're not expected to understand, but they're expected to know, instead of just don't work.

Why are they expected to know?

 

[Galenmereth]

I'd read this when it comes to eval: http://stackoverflow.com/questions/637421/is-eval-supposed-to-be-nasty

And then this: http://archive.oreilly.com/pub/a/ruby/excerpts/ruby-best-practices/worst-practices.html

Now, the reason you mostly want to avoid eval is because it is indeed a very slow process: Ruby needs to fire up its parser and tree walker to execute the code you’ve embedded in your string. It's usually harder to read, it's more error prone (usually); if it accepts user input it can wreak all kinds of havoc, and it's slow. And there are very few good reasons to use it over the alternatives in Ruby, like call / send, define_method, and procs. Just because procs are a bit awkward to learn doesn't mean it makes eval worth it. Using eval is a bad habit in almost all use cases, and firing up the interpreter during runtime to call dynamic methods is a surefire way to cause untold performance issues if you're not careful.

 

[TheoAllen]

Why are they expected to know?

Since it's a part of user config, the user should know what's the error instead of "why it doesn't work?" and realized that they did a silly stuff.

 

[Engr. Adiktuzmiko]

Been really busy lately, probably up until the 28th... So I only had the chance to visit this now.

In terms of set-up I prefer this because I prefer keeping script lines in the editor rather than the notebox, and also to clean up the notebox a bit as writing full lines or multiple lines in it can easily cause clutters.

As for speed, yeah if it's something ran only a few times then yeah maybe it doesn't matter. But if you have lots of these things that runs a number of evals per action, it really begins to matter I think. So I do think it's better if we all start to optimize things up, so that we avoid having to face those problems. 

@Hime - What Theo is trying to say is that we should let the users know what happened wrong, not that we expect users to know it from the get-go. Because Balrogic's original method was simply

$dactb[:enemy_as].send sym, user if $dactb[:enemy_as].respond_to?(sym)

Which won't return an error in case of "invalid input". This is like the damage evaluation which simply returns 0 in case of errors in the damage formula, making people's head spin sometimes trying to figure out why it deals 0 damage...

 

[Tsukihime]

@Hime - What Theo is trying to say is that we should let the users know what happened wrong, not that we expect users to know it from the get-go. Because Balrogic's original method was simply

My interpretation of the statement was that users should know why things don't work, instead of just saying "why it doesn't work?" and expecting someone else (such as the script author) to help them out or solve the problem for them.


Thanks for the clarification.