On Sep 29, 2007, at 1:46 PM, Gary Wright wrote:

>
> On Sep 29, 2007, at 2:12 PM, SpringFlowers AutumnMoon wrote:
>> Morton Goldberg wrote:
>>> On Sep 29, 2007, at 1:16 PM, SpringFlowers AutumnMoon wrote:
>>>
>>> I think it best to think of a Ruby variable as holding a  
>>> reference to
>>> an object. Ruby's reference semantics are different from C++'s, but
>>> IMO more mainstream. C++'s reference semantics are peculiar, to say
>>> the least, and perhaps even unique [*]. Ruby's variable semantics  
>>> are
>>> simple and clean when compared to C++, so I recommend forgetting
>>> about making such comparisons.
>>
>> hm... so you mean best to think of a Ruby variable as holding a  
>> pointer
>> to an object?  I hope either
>>
>> 1) we use the word "reference" to mean a pointer
>> 2) or, we just use the word pointer instead,
>
> I think that 'pointer', for most programmers, means an explicit memory
> address.  Ruby references should not be understood as explicit memory
> addresses but instead as opaque values that are processed by the
> underlying Ruby implementation as necessary to locate or 'reference'
> the associated object.
>
> At the level of a Ruby programmer I think it is best to discard the
> idea of 'pointer' entirely and think entirely about references to
> objects.  At the level of a Ruby language implementor it becomes
> necessary at some point to discuss how a Ruby reference can be
> converted to a pointer to a chunk of memory, but that is an  
> implementation
> detail that shouldn't concern a Ruby application programmer.
>
> Gary Wright
>
>
Yep.
You're not guaranteed (AFAIK) any direct memory access in Ruby, nor  
should you be concerned about it. It is Ruby. The goal is to allow  
you to focus on programming and making things happen. If you want  
access and control at a lower level, you'll need to use a language  
like C or C++ or perhaps Objective-C (don't know if Obj-C 2.0, coming  
in a month or so, will allow such low level access)
In Ruby just think about identifiers as references to objects. The  
only case that requires a little time to get a hang of is Ruby's  
Symbol class. They could be described as constant references (for the  
life of the program) and should be used carefully like globals. You  
don't want too many of them, but with any modern system you should  
have reasonable amount of headroom, unless you're dealing with a huge  
data set.
With Ruby, like SmallTalk, you're pretty much always dealing with  
objects and nothing much lower-level like pointers or primitive types.