I use *args and &block on methods that expect neither arguments nor a block as a compatibility measure. It is a paranoid way to accomodate for unexpected alterations to the method that change what a method expects. Take, for instance, the following default method in Window_Gold:
def initialize
super(0, 0, window_width, fitting_height(1))
refresh
end
Let's say someone else comes along and says that for her scene, she actually wants Window_Gold to be in the bottom right corner, not the upper left. Naturally, she could do this in smarter ways, but she decides that to do it, she will simply change the initialize method of Window_Gold to accept x and y as arguments. She does so like this:
class Window_Gold
alias she_newscene_init_2ak1 initialize
def initialize(x = 0, y = 0)
she_newscene_init_2ak1
self.x = x
self.y = y
end
end
Then, in her scene, she simply creates the window with:
@gold_window = Window_Gold.new(Graphics.width - 160, Graphics.height - 48)
OK, that's all fine - there will be no errors and her edit will work for her scene.
Now, let's say I come along and decide that for whatever reason, I am adding an instance variable to Window_Gold and I want to give it an initial value in the initialize method. So I do this:
class Window_Gold
alias ma_myvariable_init_8jh2 initialize
def initialize
ma_myvariable_init_8jh2
@my_variable = 0
end
end
Let's now say someone wants to use both our scripts and he places my script below her script. What's going to happen? When he opens her scene, he's going to get an argument error at her line:
@gold_window = Window_Gold.new(Graphics.width - 160, Graphics.height - 48)
He's going to get that error because my script overwrites the initialize method so that it does not expect any arguments, and her script is trying to pass arguments to a method which doesn't expect them.
If I had done this instead:
class Window_Gold
attr_accessor :my_variable
alias ma_myvariable_init_8jh2 initialize
def initialize(*args)
ma_myvariable_init_8jh2(*args)
@my_variable = 0
end
end
then our scripts would be immediately compatible.
Naturally, that error also would not have happened if my script had been above hers, but it is wrong to expect script users to intuit script order and, in any case, I usually instruct people to put my scripts below other custom scripts since I do alias and I know other scripters do not.
It also would not have happened if the other scripter had chosen to accomplish her goal through means which did not involve passing arguments to the initialize method, but I don't think it's a good idea to rely on the other scripter for compatibility and do nothing yourself.
I use &block for the same reason, though I must admit that while I have seen people change the expected arguments for incomprehensible reasons, I have never seen someone modify a method so that it requires a block. Still, I am a slave to paranoia, and I think that's a prudent approach when you consider the patchwork nature by which RM users collect their scripts.
For compatibility reasons then, I always use (*args, &block). I also don't think it's a good idea to change the expected input or output of a default method as my hypothetical counterpart did, but I know that some scripters do that. There might be some occasions where it's necessary or helpful, but I can't think of any off the top of my head.
With respect to your other question, there are indeed inherited methods with that name. RPG::Enemy is a subclass of RPG::BaseItem. You are right that they don't do anything by default, but they do do something if RPG::BaseItem is modified in such a way that something besides the expected "" and 0 are yielded.
The reason was
For added compatibility, I probably should have aliased those methods as well instead of relying on super as I would that way capture any other scripts which changed those methods inside RPG::Enemy itself.
Alternatively, I shouldn't have used them at all since it could lead to incompatibility if description yielded anything other than a "" or icon_index yielded anything other than 0. If they were the wrong type of object altogether, then I would get errors when I tried to draw them, and if they were such that they would only make sense in the subclasses of RPG::BaseItem that use those variables by default then they might seem out of place.
Aliasing would probably have been better than a straight overwrite and either one of those would likely have been smarter than simply calling the super method, but hey, live and learn. In answer to your question though, they are inherited methods and I did it for compatibility reasons, just not well thought out ones.
Discord
Light Style