[et_pb_section bb_built=”1″ fullwidth=”on” specialty=”off” _builder_version=”3.0.64″ next_background_color=”#000000″][et_pb_fullwidth_post_title admin_label=”Blog Post Header” _builder_version=”3.17.2″ title=”off” meta=”off” categories=”off” comments=”off” featured_placement=”background” text_orientation=”center” module_class=”blog_post_header” title_font_size=”60px” background_blend=”saturation” title_font=”Raleway|on|||” title_text_color=”#274060″ title_letter_spacing=”2px” meta_font=”Raleway||||” meta_font_size=”20″ meta_text_color=”#274060″ meta_letter_spacing=”2px” /][/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.0.63″ prev_background_color=”#000000″][et_pb_row _builder_version=”3.0.63″][et_pb_column type=”4_4″][et_pb_text admin_label=”Blog Post” _builder_version=”3.0.69″ background_layout=”light” text_orientation=”left” border_style=”solid” saved_tabs=”all” global_module=”30698″]
Originally published: IT Jungle on 1/27/2015
Updated author notes: PowerRuby has produced more recent versions that this article conveys.
Best to download the latest from PowerRuby.
In the article Testing The Ruby Waters, I introduced you to Ruby and how to use irb (the interactive Ruby shell) to easily run and test Ruby code. In this article we will expound on that and introduce more features of the Ruby programming language as it relates to an IBM i programmer – in particular, Ruby methods and one form of encapsulation.
Ruby is an object oriented language – everything in Ruby is an object. But that doesn’t inhibit Ruby from being used in a more procedural approach. Below we have a Ruby program named say_hi.rb with a method definition of hi, and then the invocation of hi. Note, Ruby methods are like subprocedures in RPG. Notice how there isn’t any sort of a class definition or any other means of encapsulating around the hi method. Ruby does have the ability to define a class, but it isn’t required, and that’s a good thing.
--- say_hi.rb ---
def hi name
puts "hi #{name}"
end
hi "Aaron"
-------
To invoke a Ruby program you need to pass the .rb file to the ruby runtime, as follows. Note I am in the same directory as the program in this case. If you are in a different directory you need to adequately convey the file path – full or relative. Also note I am in a shell environment which you can learn more about here.
Let’s mix things up a bit and copy/paste this test program into irb, as shown below. Note how I changed the order by first having the method invocation and then the method definition. Learn more about irb here.
Here we learn an interesting aspect of Ruby in that when hi was called there wasn’t yet a method definition so it threw an error. Before a method can be called upon it must first be defined. This is where we can start encapsulating our code by storing the hi method definition in a separate file, as shown below. Encapsulating (aka modularizing) is a familiar concept to RPG’ers by way of *SRVPGMs and the like.
Below we see the hi method definition now exists in file talk.rb. Then the say_hi.rb file needs to have a require_relative statement to bring the talk.rb file into say_hi.rb. Think of require_relative as being similar to a /copy statement in RPG. Note, talk.rb and say_hi.rb are located in the same directory.
--- talk.rb ---
def hi name
puts "hi #{name}"
end
-------
--- say_hi.rb --- require_relative 'talk' hi "Aaron" -------
Now when we invoke say_hi.rb again we get the expected results of “hi Aaron” in the terminal. To take this example further it would be good to wrap our hi method in a namespace so it doesn’t conflict with any other methods named hi. To do this we can use Ruby’s module concept which is similar in nature to Java’s package concept. RPG doesn’t yet have namespaces so what I usually do is prefix the subprocedure with the name of the module (i.e. Cust_getAddress).
Below we’ve added a module statement named Talk that wraps the hi method definition. We also need to declare that the hi method belongs to the Talk module so we name it self.hi instead. Why do we need to add “self.”? That’s a bigger conversation for another day, but it has to do with what’s called “mixins”.
--- talk.rb ---
module Talk
def self.hi name
puts "hi #{name}"
end
end
-------
Then in say_hi.rb we need to qualify the call to be Talk.hi. Tada! We now have namespaced methods and modularized code!
--- say_hi.rb --- require_relative 'talk' Talk.hi "Aaron" -------
Next let’s learn whether Ruby is passing parameters by value or reference – RPG can do both by using the VALUE keyword on a subprocedure definition. The prevailing user community documentation says Ruby is strictly pass-by-value but this isn’t entirely correct. The normal approach to proving Ruby is pass-by-value is to first assign a variable a value, call a method that changes the passed-in variable, and then display the original variable value again from the caller, as shown below.
--- talk.rb ---
module Talk
def self.hi name
name = "#{name}, welcome to the jungle."
puts "callee: #{name}"
end
end
-------
--- say_hi.rb ---
require_relative 'talk'
x = "Aaron"
Talk.hi x
puts "caller after call: #{x}"
-------
Now when we invoke the program again we will see the value of variable x remains the same even after the hi method changes the value of the name variable. This is where most usually say “Ha! See, obviously Ruby is pass-by-reference”.
What actually happens is a Ruby method call passes an object id reference, and if the variable is modified in the method then, and only then, it will create a new object id reference for that variable so the caller’s variable value isn’t altered. This is called copy-on-write and is an optimization strategy where two or more variables can point at the same object reference until one of them needs to change.
Let’s prove the copy-on-write concept by displaying the object id for each variable at various stages throughout the method call to see when it changes.
--- talk.rb ---
module Talk
def self.hi name
puts "n1:#{name.object_id}"
name = "#{name}, welcome to the jungle."
puts "n2:#{name.object_id}"
end
end
-------
--- say_hi.rb ---
require_relative 'talk'
x = "Aaron"
puts "x1:#{x.object_id}"
Talk.hi x
puts "x2:#{x.object_id}"
-------
Below are the results and we can see that as soon as the Talk.hi method altered the name variable it produced a new object id, and when control was returned to the caller that x still had the original object id.
From this little exercise we now know that Ruby is technically pass-by-reference but because of it’s copy-on-write approach it feels like pass-by-value. While this is definitely beyond a beginners topic I thought the distinction was important given we have both approaches in RPG, though not a copy-on-write approach. Stay tuned for more on the Ruby language in future articles.
[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row][et_pb_column type=”4_4″][et_pb_text admin_label=”Contact Form Title” _builder_version=”3.0.65″ background_layout=”dark” text_orientation=”left” border_style=”solid” saved_tabs=”all” global_module=”30700″ text_font=”Raleway|on|||” text_text_color=”#f45d01″ text_font_size=”26″ text_letter_spacing=”2px”]
Want to learn more about Ruby? Hit us up!
[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row admin_label=”Litmis Article Footer” _builder_version=”3.0.62″ background_position_1=”top_left” background_repeat_1=”no-repeat”][et_pb_column type=”4_4″][et_pb_text admin_label=”Contact Form” _builder_version=”3.0.64″ background_layout=”light” text_orientation=”left” border_style=”solid” saved_tabs=”all” global_module=”30748″]
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]