Re: what's an object?

On Fri, Nov 12, 2010 at 1:32 AM, Xavier Noria <[e-mail]> wrote:

> On Friday, November 12, 2010, zuerrong <[e-mail]> wrote:
>
> > Hi Brian,
> >
> > I just tested what you said, the result is opposite, a is changed.
>
> Point is a holds a reference, and that one can't be changed. You can
> change the state of the object it points to if it is mutable, but the
> string object is the same when the method returns because Ruby has
> pass by value semantics.
>
> I wrote a post about this a while back:
>
>     Ruby, C, and Java are pass-by-value, Perl is pass-by-reference
>     http://advogato.org/person/fxn/diary/534.html
>
> Sent from my iPad
>
>
Can we just call it "pass by object reference". Calling it "pass by value"
is so confusing, because in the code below, it sounds like you are talking
about the first function call when you are actually talking about the
second. And quite frankly, I think some people swap these definitions out
with each other. In your blog, your picture of pass by reference is actually
what I am calling pass by object reference, which you call pass by value (so
you give that as an example of not being what Ruby does, when it actually
is). It makes the entire discussion extremely difficult since different
things have the same name, and people's positions are shifting all the time.


#include <stdio.h>

typedef struct { int value; } Number;

void pass_by_value( Number number ) {
  printf("Pass by value: %d\n" , number.value );
}

void pass_by_object_reference( Number *number ) {
  printf("Pass by object reference: %d\n" , number->value );
}

void pass_by_reference( Number **number ) {
  printf("Pass by reference: %d\n" , (*number)->value );
}

int main( ) {
  Number object = { 12 };
  Number* variable = &object; /* in Ruby you interact with objects through
variables that reference them */
  pass_by_value(*variable);
  pass_by_object_reference(variable);
  pass_by_reference(&variable);
  return 0;
}


On Fri, Nov 12, 2010 at 1:51 AM, John Mair <[e-mail]> wrote:

> @Josh,
>
> I agree with Yehuda too. But I do not feel the case of Method
> objects/methods is analogous to the case of blocks/procs. The
> fundamental reason is that a very crucial point of Yehuda's argument is
> that when you on-pass the block it has the same object_id; in fact in
> Yehuda's article this point is mentioned multiple times culiminating in
> this statement:
>
> "You can tell that blocks are not being semantically wrapped and
> unwrapped
> because blocks passed along via & share the same object_id across
> methods."
>
> This semantic wrapping/unwrapping on the other hand is EXACTLY what's
> happening in the case of methods and method objects. In other words,
> what is happening with methods/method objects is precisely what Yehuda
> was arguing was *not* happening with blocks/procs.
>
> Yehuda's argument *would* apply to methods/method objects if the
> object_id remained the same across multiple calls to the method method.
> Read what he wrote again, the persistent object_id is a big part of his
> argument.
>
> To try to maintain the mental model that a method is really an object is
> actually impossible if the object keeps changing ;)
>
> It is not impossible in the case of blocks/procs however, as the
> object_id remains the same.
>
> One last example to drive it home:
>
> method(:puts).instance_variable_set(:@hello, :hello)
> method(:puts).instance_variagle_get(:@hello) #=> nil
>
> John
>
> --
> Posted via http://www.ruby-forum.com/.
>
>
Okay. I guess I will agree to disagree. For me, that is a lot of exceptional
cases to add to my understanding of the language just to explain a different
object id (which almost feels like an oversight to me, but I checked, and
the spec code doesn't address that), and I am going to opt for the elegant
model where everything is an object until such time as it becomes a
hindrance. If you don't wish to do that, I won't tell you to, though I don't
think it's a good idea to teach it to newcomers, poor Eva's head must be
spinning :P