After reading a bit in to this "Ruby in 20 min" article I'm getting a bit confused:


https://www.ruby-lang.org/en/documentation/quickstart/

Basically I don't get the lingo.... I have no clear idea of what an object, class like.... Other than everything is an object... Which does not really clarify anything. This article seems to use the terms object and class interchangeably. Can someone please clarify these basic chunks of ruby for me?

For instance does a ruby program define a class external to the script and just call the class in to an object to run code?

I don't know Ruby, but in other languages (C++, Java, Python, etc) that support Object-Oriented paradigms, a class represents a declaration/definition of some "thing", whereas an object is an instance of a class (ie. of that "thing").

For example, if you defined a class called 'Person' to represent a real person's attributes (e.g. name, age, address, etc), it would offer methods that can be called to either set or get these attributes. These attributes are stored internally within the class, oftentimes with no direct access to them other than through the "accessor" methods than can be used to set or get the attributes.

When you instantiate a 'Person' class, you then have an object in which you can actually call the methods of the class. Unless you are dealing with a special type of class known as a Singleton class, you can instantiate multiple classes of the same type. Thus a collection of one or more 'Person' objects can be grouped together.

I'm not a very good teacher, thus hopefully the basics described above will be helpful to you. Most books cover the topic of classes vs. objects in a better manner, thus if your reading material is confusing you, perhaps you should Google for additional resources.

I feel the above is a good representation of the object / class relationship. In ruby this then leads into the fact that everything is an object which means it is instantiated from a class.
In Ruby this goes all the way down to what you may normally consider to be a literal, like a number, so you can in fact call a method from the Integer class like so - 3.downto(0)

The article you have linked does examine the creation of a class (Greeter) and then following on the fact that you create an object from the Greeter class. Not sure how this is interchanging things.

Thanks this should hopefully clear things up a bit. I've been programming in Powershell only for the last year or so which can behave as both an object oriented programming language and a string language... and you're usually using it to manipulate .net classes. Thus I am thoroughly confused as to what a new programming language it talking about when it starts in with "classes" lol! I'm not a programmer and I tend to hack through code without any formality but I want to change that practice so I can communicate better!

In .Net it is pretty much the same as in Ruby, you aren't actually manipulating classes, you work on objects instantiated from classes (except fpr those cases where you invoke static class methods, but I guess that will be a later chapter in your book).

So from going back over the Ruby in 20 min link it looks like they have made a class, which is made up of methods and then made an "object" from that class. Correct? Does anyone have a good link that has some sample ruby scripts that I can look at? Being a systems admin I will not really be given a good time to learn this so maybe I can use it for systems admin scripting and learn from that...

Yes

Some of the links below may help:

http://rubylearning.com/satishtalim/tutorial.html
http://www.rubyist.net/~slagell/ruby/
http://ruby-challenge.rubylearning.org/

In the software/programming domain, the sentence above would be more commonly stated as:

The closest analogy to the word "made" would be "instantiated".

Here's the essential idea (apart from Ruby):

1. A class definition is a way of describing that certain things (specifically, "members of that class," or "subclasses" derived from this class) share common attributes (properties) and characteristics (e.g. methods). This is, in fact, a very-human notion that applies outside of programming languages. Behind the scenes, this will enable the language system to build various kinds of reference-tables and other data structures that will permit "property references" and "method calls" to work properly, given only a pointer (which is squirreled-away in each and every object ...) to these behind-the-scenes tables.
2. An object is "a hunk of memory," dynamically allocated, which is associated with a particular class-definition in some magical way, such that we say that an object is "an instance of the class(es) from which it is made. Basically, when you ask the computer to do things with this "hunk of memory," the programming language knows how to do that because an object is self-describing by virtue of being associated with a class(es). Behind the scenes, the programming language provides pointers in each block of memory .. to the tables aforementioned .. which enables the system, at runtime, to "carry out method-calls, find properties, and so forth." It Just Works.™

Now, let's take this idea one step farther, as Ruby does: anything is a class. "An integer," "a floating-point number," "a string literal," "boolean," all of these things can be thought of as "instances of a class," such that something such as 24.increment() does, in fact, have meaning: "24" is an instance of the "integer" class that is pre-defined by the programming language, and you're applying the "increment()" method to it. Likewise, say, "hello, ".append("world!").

One step more? Sure! If integer is a class ... are you allowed to extend that class with new methods of your own? Yes, you can!

It all comes down to ... chunks of memory, that are self-describing such that you can tell the computer to "do something to <this>" and the computer will be able to figure out on-the-fly what to do and then do it. Which is exactly what it does.

This concept is by no means limited to Ruby.

1 members found this post helpful.

Thanks guys this clarifies greatly and gives me something to chew on... I'll be checking out those links