Newsgroup

[Martin_DeMello1 (Martin DeMello)]

Perhaps you should introduce IRB right at the beginning, so that people
can play with more immediate examples.

That’s a very good idea. I’ll do that.

You’ll need to introduce the idea of a return value very early on,
though. Potentially a source of confusion.

One suggestion - have an ‘Objects’ section before ‘Variables’ - start
with defining an object (don’t introduce the term ‘object oriented
programming’, or classes - just make it seem like an object is the
natural unit of data storage), and then segue into variables.

I see your point. Ruby is a pure object-oriented language, so we might as
well use OO terminology. I sort of began doing that. For instance, I
began unsing the word ‘method’ right away instead of talking about
‘functions’ and then object orientation.

Now, a problem I have with this that I want to get the reader doing
something as soon as possible. It is important to engage the student.

True. There’s not much you can do with just objects.

How about this?:

I can rewrite the “Variables” chapter to introduce objects right away.
I’d change the title to “Objects”. Something like this (my comments are
in [brackets]):

<<EOH
Objects

What is an object?

An /object/ is the fundamental unit of data storage in Ruby.
Objects have a /type/ (the type of data stored in them) and a /value/
(the data itself). Some examples include:

Value Type

5      Fixnum

3.14 Float
“Hello” String

What is a variable?

A /variable/ is a name that Ruby can associate with a particular
object. For example:

city = “Toronto”

Here Ruby associates a String object (with value “Toronto”) with
the name (variable) /city/.

Think of it as Ruby making two tables. One with objects and another
with names for them. Then think of Ruby attaching a rope between
/city/ and the object “Toronto”. Whenever Ruby encounters /city/, it
will follow the string and arrive at this object.

Looks good to me. At this point a diagram would be useful, illustrating

1. an object
2. a variable pointing to an object
3. several variables pointing to the same object
4. a variable being unhooked from one object and redirected to another

I’ll work something up tomorrow and put it on the web.

What do you think about introducing the concept of an object ID at this
point? It would make clear the distinction between the object itself
(uniquely identified by its id), the data, types and methods (all of
which are various attributes of the object) and the variables that
happen to refer to it. Also, there’s the handy Object#id method so that
the student can interactively explore the way Ruby assigns IDs to
objects.

Printing variables [should I call this ‘printing objects’?]

[ Same as now ]

I’d say ‘printing objects’

Object types

We are going to look at the three most important object types:
/Fixnum/ (integers), /Float/ (decimals), /String/ (strings).

Ah - good catch. I was using Integer when I should have said Fixnum.

Maybe some more real-world analogies? Though actually I’m never sure
whether those create more confusion than they clear up.

martin

···

Daniel Carrera dcarrera@math.umd.edu wrote:

[Martin_DeMello1 (Martin DeMello)]

I was trying to avoid the term ‘polymorphism’ - ‘operator overload’ at
least looks like English And we do have to introduce at least the
concept, to explain what’s going on. How about this:

!Note: The behaviour of an operator depends on the type of its left hand
operand. This is because an operator is actually a method of the left
hand object. Thus, (5 / 3) and (5.0 / 3) involve two different
operators, whose full names are Fixnum#/ and Float#/ (read ‘the /
operator of type Fixnum’ and similarly for Float).

Maybe we should say ‘class’ instead of ‘type’ from the beginning, at
that, and use the word type only informally, as a loose synonym for
‘class’.

martin

···

Mauricio Fern?ndez batsman.geo@yahoo.com wrote:

puts 5.0/3 # → 1.666666667

!Note: Each operator is actually several different methods, depending on
the type of its left hand operand. The two we just saw are, in full,
Integer#/ and Float#/. This is sometimes referred to as ‘operator
overloading’.

Isn’t it rather just an example of polymorphism (dynamic dispatch based
on the type of the receiver)? Anyway I don’t think these terms need to be
introduced in a tutorial.

[Martin_DeMello1 (Martin DeMello)]

Excellent point. How about this:

An object is the fundamental unit of data storage in Ruby. A Ruby object
consists of

1. An ID. This is a number Ruby assigns to the object when it is
   created, and uses to keep track of the object. Every object has its own
   unique ID. Since Ruby takes care of the bookkeeping details behind the
   scenes, we don’t need to bother with the object ID ourselves, but it is
   a useful handle to grasp mentally when we want to think about a given
   object.

2. A value. This is the data stored in the object. Examples include
   numbers like 1, -2 and 3.14, and strings like “Hello World”. A value can
   also be a more complex entity, like a set of numbers, or a collection of
   several pieces of data.

3. A set of /methods/. A method is a function that acts on an object’s
   data, and returns another object. [Damn, this is hard. What’s a
   ‘function’? What does ‘return’ mean?] In a sense, the value represents
   the set of things an object /knows/, and the methods represent the set
   of things it can /do/. To get an object to do something, you /call/ one
   of its methods; this will give you back another object (known as the
   method’s ‘return value’). Methods are called using the syntax
   object.method_name. An example should make this clear - when we say
   “Hello World”.reverse
   we are calling the “reverse” method of the object “Hello World”. This
   returns another object, in this case “dlroW olleH”.

4. A /type/. Ruby has several basic types of object. A type is a
   collection of methods, so that if two objects have the same type, they
   will have the same methods (though their values might be different).
   Some of Ruby’s fundamental types are Fixnum (integers), Float (floating
   point numbers) and String (text strings).

[Diagram here]

When we create a new object, we have to specify its type. Ruby then
automatically supplies our object with all the methods that type
provides, and leaves a placeholder for the value.

There are some special types of objects that Ruby lets us create
directly by providing a value. These include Fixnum, Float and String.
Ruby can automatically deduce the types of these values, and create the
objects of the appropriate type to store them. So when you type in
“Hello World”.reverse
the following sequence of actions goes on behind the scenes:

1. Ruby sees something in double quotes, and recognises it as a String
2. A new String object is created, and supplied with all the String
   methods
3. The value of the new object is set to “Hello World”
4. Ruby sees that we are trying to call the object’s ‘reverse’ method
5. Ruby checks to see if the object has a reverse method
6. Since the object is of type String, it has automatically got a
   ‘reverse’ method, so Ruby calls it
7. The ‘reverse’ method returns a new String object whose value is the
   reversal of the original String’s
8. Ruby returns this new object to us.

Okay, that got too verbose and too technical, but it’s 3:30am I’ll
have another go at it in the morning.

martin

···

David A. Black dblack@superlink.net wrote:

Hi –

On Wed, 4 Dec 2002, Daniel Carrera wrote:

              Objects

What is an object?

An /object/ is the fundamental unit of data storage in Ruby.
Objects have a /type/ (the type of data stored in them) and a /value/
(the data itself). Some examples include:

I know you don’t want to throw everything at the learner at once,
but I wonder whether this description of objects might make it
a lot harder later to explain/grasp the idea of an object as an
entity that encapsulates behaviors as well as data – or even
without data.

Given the above description, even at the simplest level:

Object.new

you’d have to do a lot of backtracking and re-explaining to
deal with questions like, “What is the data stored in this object?
What type of data is it? What is the value of the data?”
All of which would be completely reasonable questions, based on
the data-storage-unit model.

[Gavin_Sinclair]

Perhaps you should introduce IRB right at the beginning, so that people
can play with more immediate examples.

That’s a very good idea. I’ll do that.

You’ll need to introduce the idea of a return value very early on,
though. Potentially a source of confusion.

I don’t think that’s too much trouble, actually. The reader should have no
problem with an operation producing a result. I think it’s nice that irb is a
calculator:

3 + 4
7
“Hello”
“Hello”
puts “Hello”
“Hello”
nil

Hang on! What’s that “nil”?

Well, your operation - puts “Hello” - produces a result, just like >3 + 7<.
That result is nil (i.e. nothing). The “Hello” you see is a side-effect of
the operation.

Summarising:

3 + 4
7 <— result
“Hello”
“Hello” <— result
puts “Hello”
“Hello” <— side-effect
nil <— result

EOF

It’s important to ground people in the language of “expressions”. That is, >3

• 4< is hardly an operation, it’s an expression. Well, >puts “Hello”< may
  look like an operation, and there’s no harm in considering it as such, but it
  too is an expression.

Everything you do in Ruby has a result. Some things also have side-effects.

Cheers,
Gavin

···

From: “Martin DeMello” martindemello@yahoo.com

Daniel Carrera dcarrera@math.umd.edu wrote:

[David_A_Black2 (David A. Black)]

Hi –

Maybe we should say ‘class’ instead of ‘type’ from the beginning, at
that, and use the word type only informally, as a loose synonym for
‘class’.

I definitely think so. Object#type is deprecated, and the notion of
an object being of a ‘type’ just runs the risk of making it sound
later like there’s something fishy or anomalous about singleton
characteristics and behavior on the part of objects. ‘Class’ perhaps
runs that risk a little – but it’s different, because there are Class
objects, and however an object changes over its lifetime, it’s
bootstrapped from a class. Class therefore has a direct relevance to
Ruby-space that type doesn’t.

David

···

On Wed, 4 Dec 2002, Martin DeMello wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

[Mauricio_Fernndez]

Hi –

              Objects

What is an object?

An /object/ is the fundamental unit of data storage in Ruby.
Objects have a /type/ (the type of data stored in them) and a /value/
(the data itself). Some examples include:

I know you don’t want to throw everything at the learner at once,
but I wonder whether this description of objects might make it
a lot harder later to explain/grasp the idea of an object as an
entity that encapsulates behaviors as well as data – or even
without data.

Given the above description, even at the simplest level:

Object.new

you’d have to do a lot of backtracking and re-explaining to
deal with questions like, “What is the data stored in this object?
What type of data is it? What is the value of the data?”
All of which would be completely reasonable questions, based on
the data-storage-unit model.

Excellent point. How about this:

An object is the fundamental unit of data storage in Ruby. A Ruby object
consists of

I think it’d be better to state something more abstract, without
specifically talking about data (because IMHO we need to introduce
objects as active components of the system, not as passive data).

Just for reference, here’s how the explain objects in the Blue Book:

"An object represents a component of the Smalltalk-80 software system.
For example, objects represent

• numbers
• character strings
• queues
• dictionaties
• rectangles
  […]
  An object consists of some private memory and a set of operations. The
  nature of an object’s operations depends on the type of component it
  represents. Objects representing numbers compute arithmetic functions.
  Objects representing data structures store and retrieve information.
  Objects representing positions and areas answer inquiries about their
  relation to other positions and areas.
  A message is a request for an object to carry out one of its operations.
  A message specifies which operation is desired, but not how that
  operation should be carried out. The receiver, the object to which the
  message was sent, determines how to carry out the requested operation.
  […]
  The set of messages to which an object can respond is called its
  interface with the rest of the system. The only way to interact with an
  object is through its interface."

[Goldberg, Adele. Smalltalk-80: the language and its implementation.]

1. An ID. This is a number Ruby assigns to the object when it is
   created, and uses to keep track of the object. Every object has its own
   unique ID. Since Ruby takes care of the bookkeeping details behind the
   scenes, we don’t need to bother with the object ID ourselves, but it is
   a useful handle to grasp mentally when we want to think about a given
   object.

Is this needed for beginners?

2. A value. This is the data stored in the object. Examples include
   numbers like 1, -2 and 3.14, and strings like “Hello World”. A value can
   also be a more complex entity, like a set of numbers, or a collection of
   several pieces of data.

3. A set of /methods/. A method is a function that acts on an object’s
   data, and returns another object. [Damn, this is hard. What’s a
   ‘function’? What does ‘return’ mean?] In a sense, the value represents
   the set of things an object /knows/, and the methods represent the set
   of things it can /do/. To get an object to do something, you /call/ one
   of its methods; this will give you back another object (known as the
   method’s ‘return value’). Methods are called using the syntax
   object.method_name. An example should make this clear - when we say
   “Hello World”.reverse
   we are calling the “reverse” method of the object “Hello World”. This
   returns another object, in this case “dlroW olleH”.

4. A /type/. Ruby has several basic types of object. A type is a
   collection of methods, so that if two objects have the same type, they
   will have the same methods (though their values might be different).
   Some of Ruby’s fundamental types are Fixnum (integers), Float (floating
   point numbers) and String (text strings).

Having only “duck typing”, I’m not sure whether it’s safe to introduce
types at first. Or at least, perhaps talking about classes [of
objects] rather than types, just to use OO terminology from the beginning
(so that people previously exposed to procedural languages don’t mistake
things, as having types is often confused with static typing).

···

On Wed, Dec 04, 2002 at 08:48:18AM +0900, Martin DeMello wrote:

David A. Black dblack@superlink.net wrote:

On Wed, 4 Dec 2002, Daniel Carrera wrote:

[Diagram here]

When we create a new object, we have to specify its type. Ruby then
automatically supplies our object with all the methods that type
provides, and leaves a placeholder for the value.

There are some special types of objects that Ruby lets us create
directly by providing a value. These include Fixnum, Float and String.
Ruby can automatically deduce the types of these values, and create the
objects of the appropriate type to store them. So when you type in
“Hello World”.reverse
the following sequence of actions goes on behind the scenes:

1. Ruby sees something in double quotes, and recognises it as a String
2. A new String object is created, and supplied with all the String
   methods
3. The value of the new object is set to “Hello World”
4. Ruby sees that we are trying to call the object’s ‘reverse’ method
5. Ruby checks to see if the object has a reverse method
6. Since the object is of type String, it has automatically got a
   ‘reverse’ method, so Ruby calls it
7. The ‘reverse’ method returns a new String object whose value is the
   reversal of the original String’s
8. Ruby returns this new object to us.

Okay, that got too verbose and too technical, but it’s 3:30am I’ll
have another go at it in the morning.

martin

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Make it idiot-proof, and someone will breed a better idiot.
– Oliver Elphick

[Austin_Ziegler2 (Austin Ziegler)]

An object is the fundamental unit of data storage in Ruby. A Ruby
object consists of

I would agree, in part, with Mauricio’s suggestion. In many ways, I
think it’s okay to say:

An object is the fundamental unit in Ruby. Objects can represent
numbers, text (called /String/s), collections of objects (called
/Array/s and /Hash/es), or just about anything else. In Ruby, an
object has the following characteristics:

1. An ID. This is a number Ruby assigns to the object when it is
   created, and uses to keep track of the object. Every object has
   its own unique ID. Since Ruby takes care of the bookkeeping
   details behind the scenes, we don’t need to bother with the object
   ID ourselves, but it is a useful handle to grasp mentally when we
   want to think about a given object.

I wouldn’t talk about the ID itself as the characteristic. Ruby
objects have uniqueness. How it has the uniqueness isn’t necessary
when introducing objects for the first time.

* Uniqueness. Two objects may have the same values and
  behaviours; they will still be unique objects.

Note that I don’t address the special case of Fixnum here.

2. A value. This is the data stored in the object. Examples
   include numbers like 1, -2 and 3.14, and strings like “Hello
   World”. A value can also be a more complex entity, like a set of
   numbers, or a collection of several pieces of data.

* Value. Most objects will represent values, such as numbers
  like 1, -2, and 3.14, or text strings like "Hello, World."
  Objects can also have complex or composite values, like a set
  of numbers or a collection of several pieces of data.

3. A set of /methods/. A method is a function that acts on an
   object’s data, and returns another object. [Damn, this is hard.
   What’s a ‘function’? What does ‘return’ mean?] In a sense, the
   value represents the set of things an object /knows/, and the
   methods represent the set of things it can /do/. To get an object
   to do something, you /call/ one of its methods; this will give you
   back another object (known as the method’s ‘return value’).
   Methods are called using the syntax object.method_name. An example
   should make this clear - when we say “Hello World”.reverse we are
   calling the “reverse” method of the object “Hello World”. This
   returns another object, in this case “dlroW olleH”.

* Behaviour. Objects define /methods/, which are ways that
  programs can interoperate with the object. Methods may accept
  additional data and provide the results of the method (called
  a return value). In a sense, the value represents the set of
  things an object knows, and the methods represent the set of
  things an object can do. To get an object to do something, you
  call (or invoke) one of its methods. A method call looks like
  <tt>object.method_name</tt>. If we say "Hello World".reverse,
  we are calling the "reverse" method of the String object
  "Hello World". The result of this will be another String
  object, "dlroW olleH".

4. A /type/. Ruby has several basic types of object. A type is a
   collection of methods, so that if two objects have the same type,
   they will have the same methods (though their values might be
   different). Some of Ruby’s fundamental types are Fixnum
   (integers), Float (floating point numbers) and String (text
   strings).

I agree with Mauricio here – don’t introduce type. If my suggested
modifications are used, we’ve noted that objects are unique, have
behaviour, and have value. Class can then be introduced as a
“template” or “pattern” for object behaviours and values. I can
create a unique object based on the template of a class …

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.04 at 07.50.54

···

On Wed, 4 Dec 2002 08:48:18 +0900, Martin DeMello wrote:

[Daniel_Carrera]

Okay, there have been a lot of good ideas here. Now, I’ll try to put it
all together.

1. IRB

···

======

There has been some discussion on whether we should use irb. I think I
came up with a good idea:

Chapter 1: Interactive Ruby
Start uring irb right away. Don’t introduce /puts/ or writing files.
Just use Ruby as a calculator.

Chapter 2: Objects
Essentially what I have now, but all done in irb and without /puts/.

Chapter 3: Printing
A small chapter to introduce /puts/. Give examples such as:
puts "#{num1} + #{num2} = #{num1 + #num2}"
Also introduce the difference between ‘return value’ and
’side effect’.

Chapter 4: Flow Control
Essentially what I have now. Still using irb.

Chapter 5: Putting it all together.
Show the student how to put all this in a file and run it as a
single program. This is a good excuse for adding more excercises
and examples to make the concepts of the previous chapters settle

2. Class vs type
   ================

I totally agree with saying ‘class’ instead of ‘type’. We can introduce
the ‘Object#class’ method so people can experiment. Thanks for bringing
up this point.

3. Description of Objects
   =========================

On the one hand we want to give a correct description of objects. We want
to avoid a ‘but you said…’ later on. On the other, we want to engage
the student early on and not make things too complicated. Here is my
idea:

Chapter 2: Objects
This is what I currently have:

1.  I define objects as units of data storage with a class and
    a value.
2.  I go over the Fixnum's, Float's and String's and their methods.
3.  Point out that methods are type-dependent.

*After* I've done this, I could do this:

Section:  Recap

We have already learned some characteristics of objects:

  * Value:
      Most objects will contain data, such as numbers or
      text strings.  Later on we'll see objects with more
      complex data.

  * Methods:
      Objects define /methods/, which are ways that programs can
      interoperate with the object.  In a sense, the value
      'what object knows', and a method is something the object
      can do.  For instance the object 3 knows what comes after it,
      (the /next/ method).

  * Class:
      Objects always belong to a class, like /Fixnum/, /Float/ and
      /String/.  The class is what determines which methods are
      available, and what kind of data the object holds.  For
      instance, a /Fixnum/ always holds a whole number and it
      has a /next/ method.

[I think that these briefer descriptions are enough because
 the students have already seen these in practice. ]

In addition to this, objects have an ID which identifies the object
uniquely to Ruby.

[
 I like the idea of introducing the object ID, but only briefly.
 Having the ID lets me demonstrate the difference between 12 and
 "12" better.
 What do you think?

 Introduce Object#class, Object#id, Object#display and Object#methods.
  1.- Let the student play with these.
  2.- Illustrate the difference between objects and variables.
  3.- Use '.id' to illustrate the difference between 12 and "12".
      Use other methods to illustrate this difference.
]

[Here we include Martin’s diagram]

Questions:
Perhaps this should be a separate chapter instead of a section?
What should I call it? How about “Exploring Ruby”?

4. Having a non-programmer handy
   ================================

I have a 14-year-old and a 13-year-old brother I can ask.
I agree that we should work on the tutorial before we start showing it to
programmers-to-be.

5. Fixnum vs Integer
   ====================

Fixnum and Bignum are both subclasses of the class Integer. So
technically we can use either term.

Question: Should I use the term ‘Fixnum’ or ‘Integer’?

Pro Integer: People already know what the word ‘integer’ means.
Pro Fixnum: When you type ‘3.class’ it says ‘Fixnum’.

I think I’m partial towards Fixnum.

Cheers,
Daniel

[Martin_DeMello1 (Martin DeMello)]

I wouldn’t talk about the ID itself as the characteristic. Ruby
objects have uniqueness. How it has the uniqueness isn’t necessary
when introducing objects for the first time.

• Uniqueness. Two objects may have the same values and
  behaviours; they will still be unique objects.

Note that I don’t address the special case of Fixnum here.

I feel that the “a box with an ID, that can store data and methods”
description takes care of the fundamental “what is an object,
exactly?” problem. It gives a newcomer something to point to and say
“that’s the object”, and lets him understand how we can change the data,
add and remove methods, and still have the same object through it all.
It also provides an easy and intuitive explanation for why two otherwise
identical objects are actually two separate objects that just happen to
have the same data and methods. And it provides a very easy way to
introduce ‘everything is a reference’.

2. A value. This is the data stored in the object. Examples
   include numbers like 1, -2 and 3.14, and strings like “Hello
   World”. A value can also be a more complex entity, like a set of
   numbers, or a collection of several pieces of data.

• Value. Most objects will represent values, such as numbers
  like 1, -2, and 3.14, or text strings like “Hello, World.”
  Objects can also have complex or composite values, like a set
  of numbers or a collection of several pieces of data.

Hm - important semantic distinction. Do we want to say ‘represent’ or
‘store’? I personally vote for the latter, since I think understanding
what’s going on behind the scenes, at least in general terms, helps
greatly in becoming comfortable with the language.

3. A set of /methods/. A method is a function that acts on an
   object’s data, and returns another object. [Damn, this is hard.
   What’s a ‘function’? What does ‘return’ mean?] In a sense, the
   value represents the set of things an object /knows/, and the
   methods represent the set of things it can /do/. To get an object
   to do something, you /call/ one of its methods; this will give you
   back another object (known as the method’s ‘return value’).
   Methods are called using the syntax object.method_name. An example
   should make this clear - when we say “Hello World”.reverse we are
   calling the “reverse” method of the object “Hello World”. This
   returns another object, in this case “dlroW olleH”.

• Behaviour. Objects define /methods/, which are ways that
  programs can interoperate with the object. Methods may accept
  additional data and provide the results of the method (called
  a return value). In a sense, the value represents the set of
  things an object knows, and the methods represent the set of
  things an object can do. To get an object to do something, you
  call (or invoke) one of its methods. A method call looks like
  object.method_name. If we say “Hello World”.reverse,
  we are calling the “reverse” method of the String object
  “Hello World”. The result of this will be another String
  object, “dlroW olleH”.

Nice. I’d say ‘interact’ rather than ‘interoperate’, since it sneaks
the message passing idea in.

4. A /type/. Ruby has several basic types of object. A type is a
   collection of methods, so that if two objects have the same type,
   they will have the same methods (though their values might be
   different). Some of Ruby’s fundamental types are Fixnum
   (integers), Float (floating point numbers) and String (text
   strings).

I agree with Mauricio here – don’t introduce type. If my suggested
modifications are used, we’ve noted that objects are unique, have
behaviour, and have value. Class can then be introduced as a
“template” or “pattern” for object behaviours and values. I can
create a unique object based on the template of a class …

If we go with my idea of speaking of an object as a box, containing data
and methods:

When you create a new object, such as ‘5’, it is easy to see that you
are supplying it with a value. But where does it get its methods from?
Do you have to define and store a set of methods inside every object you
create? The answer lies in another of Ruby’s fundamental concepts - the
class.

A class can be thought of as a template for creating objects. Every
object you create has to belong to a class, and the class sets up the
type of data the object stores, and the set of methods it possesses. For
instance the number 5 belongs to Ruby’s Fixnum class. Objects belonging
to the Fixum class (also known as ‘objects of class Fixnum’, ‘instances
of class Fixnum’ and ‘Fixnum objects’) have a value that is a single
integer, and a set of methods including the basic arithmetic operators.

martin

···

Austin Ziegler austin@halostatue.ca wrote:

[Austin_Ziegler2 (Austin Ziegler)]

I wouldn’t talk about the ID itself as the characteristic. Ruby
objects have uniqueness. How it has the uniqueness isn’t
necessary when introducing objects for the first time.

• Uniqueness. Two objects may have the same values and
  behaviours; they will still be unique objects.

Note that I don’t address the special case of Fixnum here.
I feel that the “a box with an ID, that can store data and
methods” description takes care of the fundamental “what is an
object, exactly?” problem.

[…]

I agree. I also think that describing an object as having
uniqueness, value, and behaviour is also a good way of saying it.
(It may not have been obvious from my splitting up the description.)
I’m thinking something like:

An object is the fundamental unit in Ruby. Objects can represent
numbers, text (called /String/s), collections of objects (called
/Array/s and /Hash/es), or just about anything else. Objects are
essentially boxes with unique identification, value, and
behaviour.

* Unique. Two objects...
* Value. Most objects...
* Behaviour. ...

2. A value. This is the data stored in the object. Examples
   include numbers like 1, -2 and 3.14, and strings like “Hello
   World”. A value can also be a more complex entity, like a set of
   numbers, or a collection of several pieces of data.

• Value. Most objects will represent values, such as numbers
  like 1, -2, and 3.14, or text strings like “Hello, World.”
  Objects can also have complex or composite values, like a set
  of numbers or a collection of several pieces of data.
  Hm - important semantic distinction. Do we want to say ‘represent’
  or ‘store’? I personally vote for the latter, since I think
  understanding what’s going on behind the scenes, at least in
  general terms, helps greatly in becoming comfortable with the
  language.

This is tough – mostly because the answer is “both.” An object
stores values to represent other values. I mean, a Car object
represents a Car in whatever program is being written – but that
Car object stores characteristics that define the Car for the
purposes of the program. It may be worth noting that objects are
representations earlier and in the Value section saying that they
store values.

[snip, the rest looks okay]

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.04 at 18.45.38

···

On Thu, 5 Dec 2002 07:31:57 +0900, Martin DeMello wrote:

Austin Ziegler austin@halostatue.ca wrote:

[Mark_Wilson]

I would add that an object can be almost anything (more than just the
things found in Ruby). An object is an abstraction of an actual thing
in the “real” world or of an idea. For example, a number is an idea.
A customer is a real thing (or person).

In a program you can create an object to represent a real customer.
This object would have attributes (name, address, credit card number,
etc.) and would have methods (know its attributes, make orders, make
complaints, etc.).

The programmer can look at the object in, at least, two ways. One way
is to build the object. This is the coding of the class of all
customers, initialization, assignment of attributes to instance
variables, definition of methods and how they are implemented – all of
these use objects provided by Ruby and can use objects created by the
programmer). The other way is as thing with interfaces. The
programmer doesn’t care, from this view, how the object was created and
coded. What matters is that when you send a message to the object
telling it what method it should perform and providing any data needed,
that the object respond as expected. Unit testing, among other things,
requires the programmer to think about the interface to the object,
often before thinking about the view of the object from the inside.

···

On Wednesday, December 4, 2002, at 06:53 PM, Austin Ziegler wrote:

On Thu, 5 Dec 2002 07:31:57 +0900, Martin DeMello wrote:

Austin Ziegler austin@halostatue.ca wrote:

I wouldn’t talk about the ID itself as the characteristic. Ruby
objects have uniqueness. How it has the uniqueness isn’t
necessary when introducing objects for the first time.

• Uniqueness. Two objects may have the same values and
  behaviours; they will still be unique objects.

Note that I don’t address the special case of Fixnum here.
I feel that the “a box with an ID, that can store data and
methods” description takes care of the fundamental “what is an
object, exactly?” problem.

[…]

I agree. I also think that describing an object as having
uniqueness, value, and behaviour is also a good way of saying it.
(It may not have been obvious from my splitting up the description.)
I’m thinking something like:

An object is the fundamental unit in Ruby. Objects can represent
numbers, text (called /String/s), collections of objects (called
/Array/s and /Hash/es), or just about anything else. Objects are
essentially boxes with unique identification, value, and
behaviour.

* Unique. Two objects...
* Value. Most objects...
* Behaviour. ...

2. A value. This is the data stored in the object. Examples
   include numbers like 1, -2 and 3.14, and strings like “Hello
   World”. A value can also be a more complex entity, like a set of
   numbers, or a collection of several pieces of data.

• Value. Most objects will represent values, such as numbers
  like 1, -2, and 3.14, or text strings like “Hello, World.”
  Objects can also have complex or composite values, like a set
  of numbers or a collection of several pieces of data.
  Hm - important semantic distinction. Do we want to say ‘represent’
  or ‘store’? I personally vote for the latter, since I think
  understanding what’s going on behind the scenes, at least in
  general terms, helps greatly in becoming comfortable with the
  language.

This is tough – mostly because the answer is “both.” An object
stores values to represent other values. I mean, a Car object
represents a Car in whatever program is being written – but that
Car object stores characteristics that define the Car for the
purposes of the program. It may be worth noting that objects are
representations earlier and in the Value section saying that they
store values.

[snip, the rest looks okay]

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.04 at 18.45.38

[Martin_DeMello1 (Martin DeMello)]

At this point, is there any reason not to mention the object id?
“Unique identification” is a rather abstract concept, whereas the idea
of uniqueness imposed via a globally unique id number is a common one
from real life. Also, knowing the mechanism involved is often helpful in
understanding and remembering why things are the way they are.

martin

···

Austin Ziegler austin@halostatue.ca wrote:

On Thu, 5 Dec 2002 07:31:57 +0900, Martin DeMello wrote:

I feel that the “a box with an ID, that can store data and
methods” description takes care of the fundamental “what is an
object, exactly?” problem.

[…]

I agree. I also think that describing an object as having
uniqueness, value, and behaviour is also a good way of saying it.
(It may not have been obvious from my splitting up the description.)
I’m thinking something like:

An object is the fundamental unit in Ruby. Objects can represent
numbers, text (called /String/s), collections of objects (called
/Array/s and /Hash/es), or just about anything else. Objects are
essentially boxes with unique identification, value, and
behaviour.

• Unique. Two objects…
• Value. Most objects…
• Behaviour. …

[Austin_Ziegler2 (Austin Ziegler)]

I think that in the part that I elided regarding uniqueness, I
mention that there is an ID; I might not mention that it’s
accessible through #id, though.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.12.05 at 20.03.14

···

On Fri, 6 Dec 2002 05:35:21 +0900, Martin DeMello wrote:

Austin Ziegler austin@halostatue.ca wrote:

An object is the fundamental unit in Ruby. Objects can represent
numbers, text (called /String/s), collections of objects (called
/Array/s and /Hash/es), or just about anything else. Objects are
essentially boxes with unique identification, value, and
behaviour.

• Unique. Two objects…
• Value. Most objects…
• Behaviour. …
  At this point, is there any reason not to mention the object id?
  “Unique identification” is a rather abstract concept, whereas the
  idea of uniqueness imposed via a globally unique id number is a
  common one from real life. Also, knowing the mechanism involved is
  often helpful in understanding and remembering why things are the
  way they are.