define_method, help on use?

[AwesomeCool]

So I found that there is a define_method function in the object class (all classes have it) that allows a scripter to create methods on the fly.

I want to know how exactly to use this method to create methods based on user settings in a script (would be very useful to me).

 

[TheoAllen]

I'm sure you already commented on my topic. Here is the example of the usage

http://forums.rpgmakerweb.com/index.php?/topic/35604-in-development-core-custom-attributes/

In a nutshell, you could define new attributes

Like a.speech, a.str, etc ...

 

[AwesomeCool]

So that's how you did that!

More people should use this function then.

Seems to make scripts much more user friendly.

 

[TheoAllen]

So that's how you did that!

More people should use this function then.

Seems to make scripts much more user friendly.

Well, not really. I havent seen any case that need to use define_method except the script I linked above

I would use procs / lambdas instead even though it will be (a bit) slower than the regular method

 

[??????]

You can also see some usage of it within my input script and key change detection scripts.

https://github.com/Dekita/Dekyde-Ace/tree/master/Input

Just had a look at your attributes script Theo.  I think you would like what I done to the whole default stat system...

 

[Lemur]

This falls in the realm of Metaprogramming, which can be notoriously slow. Avoid it unless you know for a fact you need it. In fact, if you're a newer programmer, avoid it altogether.


A grenade launcher is powerful and awesome, yes, but dang can you blow your foot off fast.

 

[TheoAllen]

This falls in the realm of Metaprogramming, which can be notoriously slow. Avoid it unless you know for a fact you need it. In fact, if you're a newer programmer, avoid it altogether.

A grenade launcher is powerful and awesome, yes, but dang can you blow your foot off fast.

Hmm.... so the new method made by define_method is slower than any regular method if they're called?

 

[Lemur]

They're not, but at the same time the chances you actually need it are slim to none. It just makes the code substantially harder to follow, often times for little to no reason.

 

[??????]

Hmm.... so the new method made by define_method is slower than any regular method if they're called?

depends...

# Not really any noticeable performance lossdefine_methodname) do |*args| args.each(&rint)end# Considerable performance loss due to the use of proc.proc = Proc.new {|*args| args.each(&rint) }senddefine_method,:name, proc)Also, imo - if you can justify it, use it.

I mean...

[*1..12].each do |digit| proc = Proc.new { trigger?("VK_F#{digit}".to_sym) } senddefine_method, "f#{digit}?", proc) end^ There was no way in hell I was writing that out manually.  For this, the amount of time the methods may* be used (*could be never) is very small, so any potential performance lost would be minimal.

Edit:

Just done some simple benchmark comparison and uhh... Seems my previous statement was sightly inaccurate.  So I shall change it..

* There is more chance of you incurring unnecessary overhead by using a proc.  The performance difference in minimal when used sparingly/effectively. However, compared to a normal method definition, it is undoubtedly slower.

(test results in spoiler)

Spoiler

This is the test results of the example (below result) of using define_method.

Calculating -------------------------------------                   A    46.898k i/100ms                   B    44.005k i/100ms                   C    50.202k i/100ms-------------------------------------------------                   A      1.459M (± 5.6%) i/s -     14.538M                   B      1.456M (± 6.1%) i/s -     14.522M                   C      1.776M (± 6.8%) i/s -     17.671MComparison:                   C:  1776229.6 i/s                   A:  1458942.9 i/s - 1.22x slower                   B:  1455862.6 i/s - 1.22x slower

module TEST  class << self      define_method(:mthoA) do |*args|      args.count    end        proc = Proc.new { |*args| args.count }    send(:define_method,:mthoB, proc)    def mthoC(*args)      args.count    end  endend

 

[Lemur]

Also, imo - if you can justify it, use it.

I mean...

[*1..12].each do |digit| proc = Proc.new { trigger?("VK_F#{digit}".to_sym) } senddefine_method, "f#{digit}?", proc) end^ There was no way in hell I was writing that out manually.  For this, the amount of time the methods may* be used (*could be never) is very small, so any potential performance lost would be minimal.

That's still unnecessary:

def f_trigger(digit)  trigger? "VK_F#{digit}".to_symend

 

[??????]

That's still unnecessary:

def f_trigger(digit) trigger? "VK_F#{digit}".to_symend

Only unnecessary if I wanted to type 'f_trigger(1)' rather than 'f1?', which I mean, why would anyone? 

 

[Lemur]

Metaprogramming for the sake of metaprogramming makes a mess. You could make it f(1) for all it really matters, but the point is that in my experience people who rely on metaprogramming make a large mess for little to no other reason than 'because it was there' or 'because it was shiny.'

 

[??????]

Perhaps, but that is not quite the reason for my using it.

I already have methods such as trigger!VK_F1) that would perform the logic I assume your suggested 'f_trigger(1)' or 'f(1)' would do.  I simply decided to add additional methods (for those who may want to use them) for quickly checking F key presses/triggers.

My reason for using meta-programming techniques to add the methods was simply because it meant I was able to quickly define 12 methods in 4 lines of code.  also felt that code like this...

def f1?; press?VK_F1); enddef f2?; press?VK_F2); enddef f3?; press?VK_F3); enddef f4?; press?VK_F4); enddef f5?; press?VK_F5); enddef f6?; press?VK_F6); end...
or

def f1?  press?VK_F1)end def f2?  press?VK_F2)end def f3?  press?VK_F3)end ...
Was taking an unnecessary amount of space.

and then the documentation for each of those methods would have been identical, its even more unnecessary.