Making method for script call

[TheoAllen]

Most of script I know that they put the method inside the Game_Interpreter to handle the script call

class Game_Interpreter def method_for_script_call msgbox("Hello World!") endendHowever, what inside the script call is competely irrelevant with the Game_Interpreter itself.

It doesnt even need @event_id, @fiber, @params, or any instance variables within the Game_Interpreter

So, it's better if it can be called everywhere.

My approach is to make a sole-method (I don't know what is this called) not tied into any classes

def method_for_script_call msgbox("Hello World!")endHowever, I heard some people don't like this idea. Is there any particullar reason for this?

An alternative way would be include the method in extra namespase like custom module

module Theo def self.method_for_script_call msgbox("Hello World") endendThought?

 

[AwesomeCool]

A reason why people do not like methods without classes is that it breaks the idea of object oriented programming.

It would be the same as making everything public (nothing is private within any class) with the reasoning that everybody should be able to touch anything for convenience.

It also can lead to more sloppy code (global methods do not have to be group together).

 

[estriole]

actually by writting:

def methodnameendit will put that method inside "Object" (the parent of class and module)

http://ruby-doc.org/core-2.1.2/Object.html

all the method from Object will be inherit by ALL class/module unless it's overriden.

it somewhat useful when there's some classes that don't have same direct parent but have same structure... (cannot think of an example though)

also we can remove it later using: 

    Object.sendremove_method, :methodname)
so basically it still Object oriented programming...

also for Scriptcall for USER to use... (not used inside script editor but event script call)

i will AVOID using module name...

i once wrap my script call using my module name (ESTRIOLE btw). and it make the script call longer and sometimes not fit the script call box.

so to make it easier... it would be better wrap it inside Game_Interpreter or even Object.method above you mentioned.

another thing... even i get bored writing my avatar name over and over again in script call box... i can't imagine another people thinking when do the same thing... so i never again wrap my USER script call inside module.

 

[Engr. Adiktuzmiko]

I normally do it the Module::method_name method... then sometimes, for the benefit of the user, I also add a wrapper for it inside game_interpreter. Though it's not much of a problem now if you have 1.02a unless it's named insanely long or have lots of parameters coz of the larger script call box.

I could also always just make sure that they won't take a really long line to write up so that I could keep them on the module without making a wrapper inside Game_Interpreter

sometimes, I also do it just to get both clear naming and the "benefit" of putting it on it's own module... so like

class Game_Interpreter  def adik_custom_menu_method1  endendScript call: adik_custom_menu_method1

vs

module ADIK_CUSTOM_MENU  def self.method1  endendScript call: ADIK_CUSTOM_MENU.method1

In this case, it doesn't even made the script call any longer

 

[Lemur]

A reason why people do not like methods without classes is that it breaks the idea of object oriented programming.


It would be the same as making everything public (nothing is private within any class) with the reasoning that everybody should be able to touch anything for convenience.


It also can lead to more sloppy code (global methods do not have to be group together).

Object Oriented programming is not a silver bullet, and its most fervent adherents tend to be among coders that I would not work with no matter how much you'd pay me. It's called shoehorning and it's bad. Use the appropriate paradigm for the task.


Also, be careful monkeypatching, that's far more likely to make a mess if you shadow something.

 

[Tsukihime]

However, what inside the script call is competely irrelevant with the Game_Interpreter itself.


It doesnt even need @event_id, @fiber, @params, or any instance variables within the Game_Interpreter


So, it's better if it can be called everywhere.

I can't say the event ID and the command list being processed are completely irrelevant when you consider the universe of script calls.


There are script calls that only operate on "this" event, but that information will not be available outside of the interpreter, requiring you to either store the event ID elsewhere for global access, or requiring the developer to pass in event_id explicitly, which you could argue is better because you're making it very clear who the script call operates on.

 

[Engr. Adiktuzmiko]

I think what Theo is saying is that the script call that he's making inside Game_Interpreter doesn't need any of those. Thus those variables become irrelevant. Which means the premise between deciding which design to choose is that the script calls in question won't need any of those variables. Like in the very simple example he's given which simply puts "Hello World".


For me the actual question is like: "If you're making a script call for the user which won't need any of the variables/methods/etc of Game_Interpreter, which design would you use?"

which you could argue is better because you're making it very clear who the script call operates on.

I would agree that it would be better, it also gives you more flexibility as you would be able to control another event/s rather than just "this" event.

 

[AwesomeCool]

I actually like the module way better, but I just gave a reason why people might no like it.

 

[TheoAllen]

A reason why people do not like methods without classes is that it breaks the idea of object oriented programming.

It would be the same as making everything public (nothing is private within any class) with the reasoning that everybody should be able to touch anything for convenience.

It also can lead to more sloppy code (global methods do not have to be group together).

It might be the answer. But I dont understand if the method for script call itself doesnt do / need anything with Game_Interpreter. The concept of Object Oriented Programming is you treat the code as an object. While sometimes, the method do not treat the Game_Interpreter as an object. It just completely irrelevant method for Game_Interpreter. If you want a group, then it's better to do with extra namespace like module. However, when you want to use script call, it means that you need to type an extra name like

ModuleName.script_callJust like estriole mentioned. It makes the script call longer and sometimes, doesnt fit the script call box.

Note : That is if your module name is longer. I have an idea to make a global script call using the module named as 'Game' instead of your avatar name or anything. So that it makes the sciprt more readable.

module Game def self.set_hour(hour) # Assume that this is a day night system script call endend

Game.set_hour(7)

I can't say the event ID and the command list being processed are completely irrelevant when you consider the universe of script calls.

There are script calls that only operate on "this" event, but that information will not be available outside of the interpreter, requiring you to either store the event ID elsewhere for global access, or requiring the developer to pass in event_id explicitly, which you could argue is better because you're making it very clear who the script call operates on.

Then this is a different case. I understand if the script call required any Game_Interpreter instance variables need to pass. But if not?

@estriole:

I just tried this.

def new_method puts "Hello World"endclass MyObject # A lot of stuff hereendobj = MyObject.newobj.new_methodAnd apparently, the 'new_method' counts as a private method.

So, yeah you're right.

 

[♥SOURCE♥]

Most of script I know that they put the method inside the Game_Interpreter to handle the script call

class Game_Interpreter def method_for_script_call msgbox("Hello World!") endendHowever, what inside the script call is competely irrelevant with the Game_Interpreter itself.

It doesnt even need @event_id, @fiber, @params, or any instance variables within the Game_Interpreter

So, it's better if it can be called everywhere.

Game_Interpreter handles event commands, if your script has methods that have to be called using Call Script, it's a good idea to put them in Game_Interpreter even if they don't use internal variables from it. Think of it as your script expanding Game_Interpreter's list of available "event" commands.

A "global" method would make less sense if you intend to call it only by using Call Script event command.

 

[TheoAllen]

Game_Interpreter handles event commands, if your script has methods that have to be called using Call Script, it's a good idea to put them in Game_Interpreter even if they don't use internal variables from it. Think of it as your script expanding Game_Interpreter's list of available "event" commands.

A "global" method would make less sense if you intend to call it only by using Call Script event command.

Nice answer. I just anticipate if you or anyone else who wants to improve the script and use the 'script call' outside the Game_Interpreter.

 

[Engr. Adiktuzmiko]

who wants to improve the script and use the 'script call' outside the Game_Interpreter.

one of the reasons why I like putting them in a module... plus my earlier example in which the module doesn't make the call any longer as I append the would-be module method name inside the method on Game_Interpreter to make it clear on it's purpose and from where it's from anyway. And on some cases, I just make a wrapper inside Game_Interpreter (like on my Lighting script), this way we have a method which can be used anywhere and a method that is shorter to call inside events.