Re: Ruby Book for People Who Aren't (Yet) Programmers

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 <[e-mail]> 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, [e-mail] on 2002.12.04 at 18.45.38
>
>
>
>