On 04.10.2010 19:31, Caleb Clausen wrote:
> On 10/3/10, Robert Klemme<shortcutter / googlemail.com>  wrote:
>> While this is technically true (because the reference actually *is* the
>> Fixnum value) I think this is a bad way to express it.  The reason is
>> that it looks into implementation details of the interpreter when one
>> tries to describe a phenomenon of the language Ruby.  It actually
>> complicates things more than necessary which IMHO hinders understanding.
>
> Rick DeNatale wrote:
>> I thing that the value of thinking of this as call by object
>> (reference) is that in languages like Smalltalk and Ruby the object
>> references are opaque, and provide a barrier between the caller and
>> the object's implementation. The only way for another object to get at
>> any state on the other side of that barrier is by sending a message to
>> the object, even if that message is instance_variable_get/set.
>
> The problem I have with this viewpoint is that you are then stuck with
> a set of strange and arbitrary (seeming) rules about how things work.
> Such as: A Fixnum is always a singleton object, whereas a Bignum is
> not.

Initially you wouldn't notice because transition from Fixnum to Bignum 
is so smooth.  But Fixnum and Bignum are just two classes.  When I think 
about Ruby's model of referencing objects and passing references around 
I usually do not focus on particular classes.  Rather I talk about 
instances and references - I don't even need to think about particular 
classes; if at all I would pick Object.

> For that matter why do we even have the distinction between
> Fixnum and Bignum at all? Why isn't there just one Integer class? If
> you don't understand the lower level representation, then these are
> real head-scratchers. They're just commandments from On High about How
> It Shall Be. Whereas if you do know the underlying realities, then
> it's not only easier to remember all this stuff, it's easier to reason
> about it as well.

That may be true when you want to reason about Fixnum, math and math 
efficiency in Ruby.  If you initially come to the language and try to 
grasp how passing of objects around works and how aliasing effects occur 
I find that point of view rather confusing than helpful because you need 
to wrap your mind around several concepts (or "levels" as you say) at 
the same time.  I'd say this is more difficult for the average human 
than focusing on one thing and then progressing to another.

> One of the important skills a programmer needs is the ability to work
> on multiple levels of abstraction simultaneously. You need to be able
> to zero in one one layer which is most relevant to the task while
> simultaneously keeping the other layers in the back of your mind; not
> completely forgotten, but  just submerged and ready to come back to
> the surface when the concerns relevant to that layer arise again.
> Knowing as many of these layers as possible makes it easier to reason
> about programs. I know it makes me a better programmer.

You are right in the long term.  But, as I said, it's something 
different if you consider learning a language (or even programming) from 
scratch.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/