Ruby Scripting

[kyonides]

Modules

What are modules in  Ruby? If you come from a language like C++, you would say a module is a namespace.

What is that? It is a container!

Yeah, the most basic explanation on modules would be that they contain stuff. I know, you are going to tell me now that classes also contain their own stuff. The truth is that they do not need to be initialized like classes do in both languages. You could say they are floating in their own space.

Yeah, you could say that each module own its own boat and it keeps navigating the vast sea separated from all classes. It is not like it hates classes, it just can live and be invoked without them. Even so you can also mix them with classes in  Ruby, something they have called a mixin. So yes, you can also use them as if they were an integral part of that specific class at will. Thus module ChipFlavors can be inserted in the Snack class to expand it by adding some sort of new toppings for all chips you can eat.

Code:

module ChipFlavors
 CHOCOLATE_CODE = 100
 MAYONNAISE_CODE = 101
 KETCHUP_CODE = 102
 MUSTARD_CODE = 103
 PEPPER_CODE = 104
end

class Snack
 include ChipFlavors
 def initialize
   @name = “”
   @price = 0
   @expire_date = “09-30-2019”
   @flavor = “”
 end
 attr_accessor :name, :price, :expire_date, :flavor
end

class Chips
 def initialize
  @name = “ChocoChips”
   @price = 2.50
   @flavor = “chocolate”
 end
end

We could add dozens of interesting chips recipes here but the point will remain the same. Our module, ChipFlavors, includes all chips flavor codes. This fact allows us to easily handle all of them in a single place without messing up with the actual classes that use them. Just imagine how tiresome it would become after a few years when we got like 50 different chips packages with different flavors.

Checking every single of them would be harsh indeed. Centralizing some specific data makes it a bit easier to handle in a timely fashion today and even in the next couple of years. If we assigned one CONSTANT of all of them to every single class, we would probably take a long time to finish that process.

Actually for a machine it might be even better to just keep the module separate without mixing it in the Snack class. If you ever need to change codes, deprecate some and so on, you would only care about a module and not every single class every time you needed to update a vending machine.

Today we have learned three things. We got modules, mixins and one that was obviously different and still got pretty much ignored, CONSTANTS.

Why do you keep yelling at me!?

O_o? I am not!

Yes, you are! Can’t you see all those capital letters?

Oh, those letters… Well, the thing is that I did that on purpose but with a different motivation. You see, they are called Constants and can be either be written like a Constant or CONSTANT. Actually, it IS a must to do that!

Say what!? Now I need to keep yelling at other people?

Do not say that! We are not breaking some rule, we are following one indeed! You see, Ruby cares about how you type stuff on your computer. Use lowercase and it will treat that word or compound as either a variable or a method. Use @ at and it will think it is an instance variable. Type @@ and it will become a class variable. Still, if you use $ dollar symbol, it will not believe it is an amount but a global variable. Anything starting with an uppercase letter will be considered to be an actual Constant. It is part of what we call a programming language’s syntax. You could say it is like its own set of grammar and punctuation rules.

No matter if you respected your teachers at school or not, Ruby will force you to respect its rules! Go against what is common sense in the rubyist world and you will not get past that point ever. Really, it is a BAD idea! There are still some obscure ways to tweak its normal behavior, but no matter how good you think you are, DO NOT DO THAT! It is better to keep it as compatible with the default Ruby implementation as possible.

By the way, you mix in modules in classes by calling the include ModuleName right below that class name. You can include as many as deemed necessary.

Just keep this in mind, use CONSTANTS to permanently store data as long as your program is active. Do Not Change Their Contents after defining them! I mean, do not ever think you can do stuff like changing their contents one hundred lines of code later. If you defined them in a specific way, keep them like that for the rest of its execution.

Of course you can update it whenever you are maintaining its code while it is not running on any machine, but do it only then. If you just load it during its testing stage, it will not really matter. Just never do it while in its production stage (whenever you are already dealing with the “real world” audience).

Then why did you mix lowercase and uppercase?

O_O I did it because you can do so if you are defining a class or module. Use uppercase (and underscore once or twice) only if you are creating a class or module CONSTANT. I mean, when it belongs to that class or module.

I have seen people nesting classes and modules at will. Why’s that?

Err, well, you could say they are free to do so. For instance, you could define a single module and then lots of classes inside… like the RPG module in the maker series. Stuff like RPG::Actor and so on are a “living proof” of it. Double colon :: mean the connection there is between the container module and its inhabiting class. To be honest with you, you can do that with two different classes as well. There the difference would be that the first class might call the second class as some sort of helper class that might contain stuff you deliberately wanted to separate from the main class. RPG::Event and its subclasses are an excellent example here. The sections you can see in the event editor might belong to either the main or the secondary classes.

This is why I cannot stop repeating myself. Everything depends on your coding style at the end.

Is there anything else I might need to know about modules?

O_o? I am uncertain if you really need to know this, but Module is a class. Yeah, even if it sounds weird, that is exactly what it is, just another Ruby class. What makes it important is that it does not ask you to initialize it and you can place it pretty much anywhere, and it keeps your code neat. For example, in my unreleased games KUnits and A Short Odyssey Gosu versions I keep language support stuff separated from scene classes to keep it easy to maintain. There I usually use the Lang or Terms module for such purposes. Yeah, there are many ways to deal with it but I just picked one of them because I felt like it.

Guess what? There is something else you might need to learn about them.

What is it?

Modules can contain more than just CONSTANTS. You can place floating methods there as well. That is not an official term, it just attempts to teach you they are not officially part of that module.

That’s impossible! You gotta be kidding me!!

O_o? Nope, I am not. The main idea behind it is that you should be able to do the same you have done with CONSTANTS as with any method you would like to include in one or more classes where you will include that module of yours.

So what happens to those methods after the mixin!?

They kind of become part of that class’s list of methods. Yeah, you could not distinguish them from the rest if you print the whole list! That is what makes them run smoothly as if they had always been there!

Are you saying modules will never own any methods ever!?

Err, nope, I never said so. There IS a way to make it own any specific method. You see, so far we have only seen that methods are called by typing the def keyword followed by some method_name. Normally that means that method will belong to a class. To change that in a module, we can add something special there. It is the self keyword!

Code:

module MyModule
 def self.method_name
   print “I belong to MyModule only!”
 end
end

Yes, it only belongs to that module now! In English it might be self evident what self actually means. For those speaking foreign languages (like your lazy servitor here), it might be strange to see how it is used. Honestly, it just means “I” or “me” own this method so call me first to access it properly. It is a simple replacement for that module’s name, meaning it will also work if you type that name instead. Since self is shorter and easy to understand, the convention is that you would just type self and not the module’s name there.

What if I’ve got plenty of module methods!?

Do not worry then! There is a simple way to avoid typing all those dozens of egotistic self.

Use module_function in a separate line and all methods written below will become module methods by default. Again, I told you Ruby lets you become lazy scripters.

There is also another way to make those methods become singleton methods (belonging to that module).
Just type extend self and it will take care of all of the methods defined beneath that line.
It has an advantage over module_function, it will let you use attr_ methods like those we have seen in my previous posts as if we were dealing with a class and not a module.

Keep in mind that such methods will NEVER become part of a class where you have mixed it in. You will still need to call it by typing MyModule.method_name every single time you need to trigger them there.

Right, I forgot to reveal another important fact about modules, you can call its module methods from anywhere! Once they have been properly defined, you can access them from any other script defined after that module has been defined.

Happy ArgumentError Message Debugging Nights!