On Mon, Oct 4, 2010 at 1:31 PM, Caleb Clausen <vikkous / gmail.com> 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. =A0The reason is
>> that it looks into implementation details of the interpreter when one
>> tries to describe a phenomenon of the language Ruby. =A0It 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. 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.

But singleton (or immediate) vs non immediate isn't really the issue here.

Fixnums and Bignums are both immutable,  so if you are thinking at the
level of the language you can't tell the difference in the context of
argument passing or assignment.

And just where the boundary is between Fixnums and Bignums is
implementation dependent, so it's best when writing Ruby code not to
dwell on the fact that both exist.

Yes I know, you can make Fixnums mutable in a sense by adding
singleton methods which attach instance variables, but that's a very
strange edge-case, and if you play stupid ruby tricks like that you
need to be able to deal with it.


> 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 =A0just 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.

Agreed, but it cuts both ways.  I can understand that someone coming
to Ruby from the viewpoint of a C programmer is tempted to think in
terms of bits and bytes, but for approaching understanding Ruby one
needs to let go and think first at a higher level of abstraction.

In most cases, when programming Ruby one doesn't really need to dive
that deeply into the implementation.


--=20
Rick DeNatale

Help fund my talk at Ruby Conf 2010:http://pledgie.com/campaigns/13677
Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale