<commit_before>---
layout: post
title:  "Oh Module where art thou?"
date:   2016-09-19 22:19:00 -0400
---

Under the canopy of a lustrious tree, laid our camping ground. Haphazardly set up due to fatigue from our long treck into the heart of the Ruby jungle. I've been logging our discoveries in my journal since we started this treck. 

You accidentally left your walking stick behind? Let me see, maybe I wrote down where you last left it in [Reaching the end of the Ruby Class Jungle](http://juangongora.github.io/2016/08/19/reaching_the_end_of_the_ruby_class_jungle/).

Okay, here it says that we stopped by a couple of different places. Let's see...

1. Variables which begin with two @@ characters are called *class variables*. They give you automatic sharing throughout the class's hierarchy.

2. *Class methods* (also referred to as [*singleton methods*](http://www.rootr.net/rubyfaq-8.html#singleton_method)) are for things that don’t operate on the individual instance of an object, or for cases where you don’t have the instance available to you. It’s primary use is for updating all users of the class to a specific condition.

3. In the context of a class, `self` refers to the current class, which is simply an instance of the class [`Class`](https://ruby-doc.org/core-2.2.0/Class.html). Defining a method on `self` creates a *class method*.

4. With *attribute accessors*, Ruby provides us with an easy way to access an object’s variables. An *[attribute accessor](http://www.rubyist.net/~slagell/ruby/accessors.html)* is the property of an object whose value can be read and/or written through the object itself.

Did that help you remember where you left it? Oh good, let's pack up and get it then. While we're walking there, let's make a plan to get ready to go into that massive Ziggurat. You know, the one we camped outside of... That location has been what we've been searching the whole jungle for after all!

Okay, so the first clue we got from trying to pry into the Ziggurat was that it's built on numerous different levels. It mentioned that our first entrance would lead us to the "Hall of Modules". *Modules*, that word sounds familiar... In fact, I think the *attribute accesors* we worked on in the last blog are related to *Modules*!

Before we get ahead of ourselves though, let's check out the map:

Alright it looks like *Class* leads us to *Module*. 

<a href="http://imgur.com/yiZovC1"><img src="http://i.imgur.com/yiZovC1m.jpg" title="source: imgur.com" /></a>

We already know what classes are thanks to our earlier trecks(from [here](http://juangongora.github.io/2016/06/28/getting_to_know_classes_in_ruby/), to [there](http://juangongora.github.io/2016/07/17/diving_deeper_into_rubys_class_pool/), and [back](http://juangongora.github.io/2016/08/19/reaching_the_end_of_the_ruby_class_jungle/) again!). 

Let's refresh the mind for old time's sake. Classes are objects, just like almost everything else in Ruby. But they're also the only type of object that's capable of summoning *new* objects: through *[instantiation](https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instantiation)*. Classes can send and recieve messages to their objects, as well as add methods and arguments to other objects.

You can even make new classes in the same fashion that you would when making a new object variable:

`gold = Class.new`

Here we are assigning the *Class* constructor to the variable `gold`, which is now capable of making *instantiated* versions of itself:

`nugget = gold.new`

We can even tweak the *[unnamed class](https://ruby-doc.org/core-1.9.3/Class.html#method-c-new)* of `gold`(which is just assigning a new instance of the class `Class` to the variable named `gold`) to have it's own built in *instance methods* upon creation!

```
gold = Class.new do
  def rich
    puts "I found me some gold!!"
  end
end

nugget = gold.new

p nugget.rich
```

Terminal:

```
I found me some gold!!
nil
```

You might be getting confused though about why `nugget` is able to function as a class... Even though it's a [*local variable*](http://ruby-doc.org/docs/ruby-doc-bundle/UsersGuide/rg/localvars.html), and not a [*constant*](http://ruby-doc.org/docs/ruby-doc-bundle/UsersGuide/rg/constants.html): which is the more formal way that you and I know about class creation:

```
class Gold

  def rich
    puts "I found me some gold!!"
  end

end
```

The reason behind this is that all classes(including newly made classes) that have been *instantiated*, are actually *instances* coming from the class `Class`. So the class `Gold` written above is an *instance* of `Class`, and `Class` already comes built with the `new` method. This is why we can do this for both the versions that were described:

```
# from the local variable assigned to instantiate from Class

gold = Class.new

# from an instantiated variable of the new class Gold

instance_of_Gold = Gold.new
```

You should probably know that there actually are two different forms of `new` for the parent class `Class`. One is an *instance method*, and the other is a *class method*. So when you use `Class.new`, you're actually incorporating a *class method* from the parent class `Class`. While using `Gold.new` uses an *instance method* that was ancestored from `Class`.

Ahhh there's your walking stick! Let's head back to the Ziggurat now: 

<a href="http://imgur.com/PT201cK"><img src="http://i.imgur.com/PT201cKl.jpg" title="source: imgur.com" /></a>

Phew!! Those were quite a lot of steps just to get to the entrance! Alright I'm going to have to turn on my flashlight, it looks pretty dark in there. Huh? What's this? inscribed on the floor... It says:

> The superclass of Class is Module

Just like our map said! It looks like if we continue going forward there's more writing for us to see. Let me take out my journal and jot down what we see as we go further in. Can you aim the light for me?

Okay, so... Modules are actually very similar to classes in that they also contain methods and constants. They don't however contain *instances* that are traditonally called like our classes are(i.e. no object can be created from a module). BUT, they can hold these *instance variables/methods* inside the module itself, which could then be passed *into* a class(in order to build up [*multiple inheritance*](http://www.tutorialspoint.com/ruby/ruby_modules.htm)). We have ofcourse, already been using modules. Among these modules were the *attribute accessors* from the previous blog:

```
class Sheriff
  attr_reader :dog
  attr_writer :dog
	
end
```

Those method calls are passing [*symbols*](http://www.troubleshooters.com/codecorn/ruby/symbols.htm), which then cause Ruby to create an *instance variable* called `@dog`. Ruby takes the value of *symbols* quite literally, in that its value also becomes its name. From this the *accessor methods* will create methods and variables that match the name of the *symbol*. These method calls then go directly to the class object `Sheriff`, which points to its default object `self`.

As you can see from having used the *attribute accessors*, instances of `Class` therefore have access to the *instance methods* defined in `Module`'s [default private methods](http://ruby-doc.com/docs/ProgrammingRuby/html/ref_c_module.html). From there, the classes then begin to create their OWN *instance variables*.

To spiral back to the hierarchy of Ruby's inheritance, every class object is ALSO a module object. We did however, bring up classes first because of the fact that Ruby is object-oriented; and objects are *also* instances of classes. But you could say that modules are the more basic structure of the two.

So what exactly are modules used for? This can be answered in two words: [*namespaces*](http://stackoverflow.com/questions/991036/what-is-a-namespace) and [*mixins*](https://www.sitepoint.com/ruby-mixins-2/). 

Imagine modules as boxed containers that have methods, constants and classes inside. All of the different items inside this container are made by the same *"company"* so they share the same *"brand"*(or *namespace*) which makes them visible to each other, but not to anyone that is looking just outside of the box(like a window shopper).

So how do we access these? Let's make a sample module and find out:

```
module Artifact

  Shiny = "This is a constant variable"

  def self.fragile
    puts "This is a class method"
  end
  
  def fragile
    puts "This is an instance method"
  end
  
end
```

Okay let's first attempt to access the constant inside of the module `Artifact`:
<a id="target">
```
puts Artifact::Shiny
```
</a>
Terminal:
<commit_msg>update blog<commit_after>---
layout: post
title:  "Oh Module where art thou?"
date:   2016-09-19 22:19:00 -0400
---

Under the canopy of a lustrious tree, laid our camping ground. Haphazardly set up due to fatigue from our long treck into the heart of the Ruby jungle. I've been logging our discoveries in my journal since we started this treck. 

You accidentally left your walking stick behind? Let me see, maybe I wrote down where you last left it in [Reaching the end of the Ruby Class Jungle](http://juangongora.github.io/2016/08/19/reaching_the_end_of_the_ruby_class_jungle/).

Okay, here it says that we stopped by a couple of different places. Let's see...

1. Variables which begin with two @@ characters are called *class variables*. They give you automatic sharing throughout the class's hierarchy.

2. *Class methods* (also referred to as [*singleton methods*](http://www.rootr.net/rubyfaq-8.html#singleton_method)) are for things that don’t operate on the individual instance of an object, or for cases where you don’t have the instance available to you. It’s primary use is for updating all users of the class to a specific condition.

3. In the context of a class, `self` refers to the current class, which is simply an instance of the class [`Class`](https://ruby-doc.org/core-2.2.0/Class.html). Defining a method on `self` creates a *class method*.

4. With *attribute accessors*, Ruby provides us with an easy way to access an object’s variables. An *[attribute accessor](http://www.rubyist.net/~slagell/ruby/accessors.html)* is the property of an object whose value can be read and/or written through the object itself.

Did that help you remember where you left it? Oh good, let's pack up and get it then. While we're walking there, let's make a plan to get ready to go into that massive Ziggurat. You know, the one we camped outside of... That location has been what we've been searching the whole jungle for after all!

Okay, so the first clue we got from trying to pry into the Ziggurat was that it's built on numerous different levels. It mentioned that our first entrance would lead us to the "Hall of Modules". *Modules*, that word sounds familiar... In fact, I think the *attribute accesors* we worked on in the last blog are related to *Modules*!

Before we get ahead of ourselves though, let's check out the map:

Alright it looks like *Class* leads us to *Module*. 

<a href="http://imgur.com/yiZovC1"><img src="http://i.imgur.com/yiZovC1m.jpg" title="source: imgur.com" /></a>

We already know what classes are thanks to our earlier trecks(from [here](http://juangongora.github.io/2016/06/28/getting_to_know_classes_in_ruby/), to [there](http://juangongora.github.io/2016/07/17/diving_deeper_into_rubys_class_pool/), and [back](http://juangongora.github.io/2016/08/19/reaching_the_end_of_the_ruby_class_jungle/) again!). 

Let's refresh the mind for old time's sake. Classes are objects, just like almost everything else in Ruby. But they're also the only type of object that's capable of summoning *new* objects: through *[instantiation](https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instantiation)*. Classes can send and recieve messages to their objects, as well as add methods and arguments to other objects.

You can even make new classes in the same fashion that you would when making a new object variable:

`gold = Class.new`

Here we are assigning the *Class* constructor to the variable `gold`, which is now capable of making *instantiated* versions of itself:

`nugget = gold.new`

We can even tweak the *[unnamed class](https://ruby-doc.org/core-1.9.3/Class.html#method-c-new)* of `gold`(which is just assigning a new instance of the class `Class` to the variable named `gold`) to have it's own built in *instance methods* upon creation!

```
gold = Class.new do
  def rich
    puts "I found me some gold!!"
  end
end

nugget = gold.new

p nugget.rich
```

Terminal:

```
I found me some gold!!
nil
```

You might be getting confused though about why `nugget` is able to function as a class... Even though it's a [*local variable*](http://ruby-doc.org/docs/ruby-doc-bundle/UsersGuide/rg/localvars.html), and not a [*constant*](http://ruby-doc.org/docs/ruby-doc-bundle/UsersGuide/rg/constants.html): which is the more formal way that you and I know about class creation:

```
class Gold

  def rich
    puts "I found me some gold!!"
  end

end
```

The reason behind this is that all classes(including newly made classes) that have been *instantiated*, are actually *instances* coming from the class `Class`. So the class `Gold` written above is an *instance* of `Class`, and `Class` already comes built with the `new` method. This is why we can do this for both the versions that were described:

```
# from the local variable assigned to instantiate from Class

gold = Class.new

# from an instantiated variable of the new class Gold

instance_of_Gold = Gold.new
```

You should probably know that there actually are two different forms of `new` for the parent class `Class`. One is an *instance method*, and the other is a *class method*. So when you use `Class.new`, you're actually incorporating a *class method* from the parent class `Class`. While using `Gold.new` uses an *instance method* that was ancestored from `Class`.

Ahhh there's your walking stick! Let's head back to the Ziggurat now: 

<a href="http://imgur.com/PT201cK"><img src="http://i.imgur.com/PT201cKl.jpg" title="source: imgur.com" /></a>

Phew!! Those were quite a lot of steps just to get to the entrance! Alright I'm going to have to turn on my flashlight, it looks pretty dark in there. Huh? What's this? inscribed on the floor... It says:

> The superclass of Class is Module

Just like our map said! It looks like if we continue going forward there's more writing for us to see. Let me take out my journal and jot down what we see as we go further in. Can you aim the light for me?

Okay, so... Modules are actually very similar to classes in that they also contain methods and constants. They don't however contain *instances* that are traditonally called like our classes are(i.e. no object can be created from a module). BUT, they can hold these *instance variables/methods* inside the module itself, which could then be passed *into* a class(in order to build up [*multiple inheritance*](http://www.tutorialspoint.com/ruby/ruby_modules.htm)). We have ofcourse, already been using modules. Among these modules were the *attribute accessors* from the previous blog:

```
class Sheriff
  attr_reader :dog
  attr_writer :dog
	
end
```

Those method calls are passing [*symbols*](http://www.troubleshooters.com/codecorn/ruby/symbols.htm), which then cause Ruby to create an *instance variable* called `@dog`. Ruby takes the value of *symbols* quite literally, in that its value also becomes its name. From this the *accessor methods* will create methods and variables that match the name of the *symbol*. These method calls then go directly to the class object `Sheriff`, which points to its default object `self`.

As you can see from having used the *attribute accessors*, instances of `Class` therefore have access to the *instance methods* defined in `Module`'s [default private methods](http://ruby-doc.com/docs/ProgrammingRuby/html/ref_c_module.html). From there, the classes then begin to create their OWN *instance variables*.

To spiral back to the hierarchy of Ruby's inheritance, every class object is ALSO a module object. We did however, bring up classes first because of the fact that Ruby is object-oriented; and objects are *also* instances of classes. But you could say that modules are the more basic structure of the two.

So what exactly are modules used for? This can be answered in two words: [*namespaces*](http://stackoverflow.com/questions/991036/what-is-a-namespace) and [*mixins*](https://www.sitepoint.com/ruby-mixins-2/). 

Imagine modules as boxed containers that have methods, constants and classes inside. All of the different items inside this container are made by the same *"company"* so they share the same *"brand"*(or *namespace*) which makes them visible to each other, but not to anyone that is looking just outside of the box(like a window shopper).

So how do we access these? Let's make a sample module and find out:

```
module Artifact

  Shiny = "This is a constant variable"

  def self.fragile
    puts "This is a class method"
  end
  
  def fragile
    puts "This is an instance method"
  end
  
end
```

Okay let's first attempt to access the constant inside of the module `Artifact`:
<p id="target">
```
puts Artifact::Shiny
```
</p>
Terminal:

{'fraction_non_alphanumeric': 0.0863725830728262, 'fraction_numerical': 0.008799351626722242, 'mean_word_length': 4.32521578298397, 'pattern_counts': {'":': 0, '<': 19, '<?xml version=': 0, '>': 21, 'https://': 8, 'lorem ipsum': 0, 'www.': 10, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4886581', 'n_tokens_mistral': 5062, 'n_tokens_neox': 4741, 'n_words': 2447}