Everything is an Object!

Craig Bradley — Sun, 28 Oct 2018 14:16:12 +0000

Everything is an object. You may have heard this phrase before, but what does it mean?

What is an object?

An object refers to a particular instance of a class with their own methods or procedures and data variables meaning that everything is an instance of a class.

Types are objects

In statically typed languages we can define variables of different types and those variables are not objects, they don't have methods and don't have any attributes. We could say that dynamically types languages define types as classes, so for example if you have a string, it's an instance of the String class.

Let's take a look at some examples in ruby:

True/False/Nil

# Define a boolean and store as a variable my_bool
my_bool = true # => true 

# Can call the class method to return the class of the object
my_bool.class # => TrueClass

# The superclass of TrueClass is Object
TrueClass.superclass # => Object

# my_bool is an object
my_bool.is_a?(Object) # => true

my_bool = false # => false
my_bool.class # => FalseClass
FalseClass.superclass # => Object
my_bool.is_a?(Object) # => true

my_nil = nil # => nil
my_nil.class # => NilClass
NilClass.superclass # => Object
my_nil.is_a?(Object) # => true

Strings

my_string = "Some string" # => "Some string"
my_string.class # => String
String.superclass # => Object
my_string.is_a?(Object) # => true

Okay, great, strings, booleans and nil are objects but what about other datatypes?

More Datatypes

# Define an array of values with different types
my_array = [1, "two", :three, { "four" => 4 }, [5]]

# List of each objects type class
classes = my_array.map(&:class) # => [Integer, String, Symbol, Hash, Array]

# Every type class eventually inherits from object
classes.map(&:superclass) # => [Numeric, Object, Object, Object, Object]

# An Integer has a superclass of Numeric, Numeric has a superclass of Object
Numeric.superclass # => Object

# All values in my_array are objects
my_array.map { |val| val.is_a?(Object) } # => [true, true, true, true, true]

So every variable that you create is an object and this probably doesn't come as a surprise. However, what about classes? Are they objects? Yes (at least in ruby).

Classes are objects

Classes in Ruby are first-class objects — each is an instance of class Class.

So let's take a look at what this means -
When we create a class in ruby we usually use the following syntax:

# Define new class Foo
class Foo
end

# Foo is an object
Foo.is_a?(Object) # => true

but what is really happening under the hood? It might make more sense if we define a class using different syntax:

# Define new class Foo
Foo = Class.new
Foo.is_a?(Object) # => true

This does exactly the same as the traditional method above does, but I think this makes it more clear as to what is happening. Whenever you create a new class, you're really creating a new instance of Class. You're creating objects. This object is then assigned to a constant as you only want one instance of it. You can see all constants by calling the constants method on Module. See below a cut down list of constants.

Module.constants # => [:String, :Float, :NilClass, :Hash, :Array,
# :Integer, :TrueClass, :FalseClass, :Numeric, :Fixnum, :Range, 
# :Foo, :BasicObject, :Object, :Module, :Class, :Symbol]

You can see that our Foo class that was created earlier has been added to this list of constants. Every constant in this list is an object.

Object Id's

Every object in ruby has a unique id and this can be accessed by calling object_id. Using this method we can see which objects have the same id's and there are also some interesting results. Constants will maintain the same id until execution is halted. There are no guarantees that constants will maintain the same id when the program is executed again. There are exceptions to this rule however, which I will discuss now.

True/False/Nil

true1 = true
true2 = true
true1.object_id # => 20
true2.object_id # => 20

false1 = false
false2 = false
false1.object_id # => 0
false2.object_id # => 0

nil1 = nil
nil1 = nil
nil1.object_id # => 8
nil2.object_id # => 8

true, false and nil are special cases and these will maintain the same object_id every time the program is executed. There is only ever one instance of each of these values.

Integers

int_a = 1
int_b = 1
int_a.object_id # => 3
int_b.object_id # => 3

int_a = 2
int_b = 2
int_a.object_id # => 5
int_b.object_id # => 5

int_a = 3
int_b = 3
int_a.object_id # => 7
int_b.object_id # => 7

Every integer in ruby has it's own unique id and this will never change. Whenever you refer to a variable of 234, you're referring to exactly the same object. You might have noticed a pattern in the object_id's for integers. If you bit shift the integer to the left by one and add one, you will get the objects id. Vice versa if you bit shift the objects id to the right, you will get the integer. I believe this is for performance reasons.

Symbols

my_sym1 = :foo
my_sym2 = :foo
my_sym1.object_id # => 1280988
my_sym2.object_id # => 1280988

Symbols are immutable. The first time you create the symbol :foo it will create a new object and store it in a list which you can access via Symbol.all_symbols. The second time, we already have a :foo symbol in the list and therefore it will reference this one. Symbols are created once and referenced multiple times, they cannot be changed.

Strings

my_string1 = "foo"
my_string2 = "foo"
my_string1.object_id # => 70093438879580
my_string2.object_id # => 70093438872080

Strings are mutable and therefore whenever you create two strings that are equal, you'll get different objects. Although we've created two variables, both with the same value "foo" they are different objects.

So everything is an object?

When we say everything is an object, the everything part is a bit vague. Methods, blocks and operators are not objects. The lines are a little blurry with methods and blocks as they can be interpreted as objects.

Methods

# Declare a new method foo
def foo
  puts "test"
end

# Get a wrapped version of foo
my_method = method(:foo)

# my_method is an instance of Method
my_method.class # => Method

# Method has a superclass of Object
Method.superclass # => Object

# Can invoke the method using call
my_method.call # => "test"

It's unclear whether methods are actually objects or not. They behave like objects but you can never access the method directly. You will always get a wrapped version of the method which acts like a closure. I would be tempted to say that methods are not objects.

Summary

To summarise, almost everything in ruby is an object. Every data type that we work with is a class and classes are objects. Even the Object class is an object. Strings, integers, floats, hashes, arrays, symbols, classes, modules, errors and more are all objects. Open up an irb console and see for yourself, there are some really interesting observations to make.

The Power of a Todo List Project

Craig Bradley — Sun, 21 Oct 2018 17:59:10 +0000

I'm aware that there are several posts about how a Todo list can be demotivating, however I think they still have their place. There are several reasons developers choose to develop a Todo list, especially when learning a new language or learning to code. The main reason is that it's simple yet complex enough to explore most features of a language, which is great for beginners and experienced developers.

For a beginner it can be a daunting experience trying to choose the perfect project. A Todo list can be broken down easily and implemented as several separate components, which makes a perfect first project. It allows for faster results and reduces the feedback loop. There is nothing more motivating than seeing results quickly, especially for a beginner.

For more experienced developers trying their hand at a new language, it is complex enough that it will really allow you to explore the full range of features a language offers. The list itself will get you thinking about data structures and it's items about data types and object orientation. Creativity is the only boundary and this is still true for a Todo list.

So what components can we break a Todo list down in to. The most obvious starting point is the list itself and this should get us thinking about what data structure to use. I'd tend to go with the simplest of structures first which would be an array. Then if we think about data types, an item could initially be a string. Without a list, we can't implement the other components:

Adding an item
Removing an item
Displaying items
Ordering items

Future changes such as setting "done by" dates might force us to change the data type of an item. I'll avoid going into more detail about software design at this point, but for more experienced developers this could be another consideration.

There are examples of Todo lists in every single language and this is great help especially for beginners. Being able to implement something and then look at how others have done so is a great way to learn.

So to wrap up, I still think there are major benefits from a traditional Todo list project. It might not be the most exciting of projects but it really does allow you to explore a language and for me this is the most exciting thing.

If you feel I've missed any important points or you disagree then feel free to leave a comment with what is missing or what you disagree with.

Forem: Craig Bradley

Everything is an Object!

What is an object?

Types are objects

True/False/Nil

Strings

More Datatypes

Classes are objects

Object Id's

True/False/Nil

Integers

Symbols

Strings

So everything is an object?

Methods

Summary

The Power of a Todo List Project