what's an object?

Discussion in 'Ruby' started by Eva, Nov 11, 2010.

  1. Eva

    Eva Guest

    SSdtIGFsc28gc3dpdGNoaW5nIGZyb20gcGVybCBhbmQgcGhwLgpJJ20gbm90IHN1cmUgaW4gcnVi
    eSB3aGF0J3MgYW4gb2JqZWN0LgpJdCBzZWVtcyBlYWNoIGluc3RhbmNlIG9mIGEgY2xhc3MgaXMg
    YW4gb2JqZWN0LCBpcyBpdD8KClRoYW5rcy4K
    Eva, Nov 11, 2010
    #1
    1. Advertising

  2. Eva

    Alex Stahl Guest

    [Note: parts of this message were removed to make it a legal post.]

    Simple answer: everything. Everything is considered an object,
    including an instance of a class, the class itself, its methods, etc.
    No primitives, just objects.


    ________________________________________________________________________

    Alex Stahl | Sr. Quality Engineer | hi5 Networks, Inc. |
    |

    On Wed, 2010-11-10 at 19:50 -0600, Eva wrote:

    > I'm also switching from perl and php.
    > I'm not sure in ruby what's an object.
    > It seems each instance of a class is an object, is it?
    >
    > Thanks.
    Alex Stahl, Nov 11, 2010
    #2
    1. Advertising

  3. Eva

    Y. NOBUOKA Guest

    > Simple answer: everything. Everything is considered an object,
    > including an instance of a class, the class itself, its methods, etc.


    There is one thing incorrect.
    In Ruby, an instance of a class or a class itself is exactly an object,
    while a method is NOT an object.

    Although we can obtain a Method object using the *Object#method*
    method [ http://ruby-doc.org/core/classes/Object.html#M000336 ], a
    method itself is not an object.

    --
    NOBUOKA Yuya
    Y. NOBUOKA, Nov 11, 2010
    #3
  4. Eva

    zuerrong Guest

    2010/11/11 Alex Stahl <>:
    > Simple answer: =C2=A0everything. =C2=A0Everything is considered an object=

    ,
    > including an instance of a class, the class itself, its methods, etc.


    class itself is the instance of Class class, so a class is exactly an objec=
    t.

    > Class.class

    =3D> Class

    But Class is the instance of itself, I can't understand for this. who
    can help explain?


    --=20
    Kind regards,
    =C2=A0 =C2=A0 =C2=A0Zuer (=E7=A5=96=E5=84=BF)
    zuerrong, Nov 11, 2010
    #4
  5. Eva

    timr Guest

    On Nov 10, 5:50 pm, Eva <> wrote:
    > I'm also switching from perl and php.
    > I'm not sure in ruby what's an object.
    > It seems each instance of a class is an object, is it?
    >
    > Thanks.


    Classes are tables of defined behaviors (i.e. methods). An instance of
    a class is indeed an object, as you noted. When a message is sent to
    an object ("some string".upcase, "some string".reverse, "some
    string".split('') etc.), the object looks inside the class that
    instantiated it to see if it has the definition for that method. If
    not it looks higher up the class ancestry chain to find the
    definition. It may surprise you coming from perl and php that some
    very basic things are objects in ruby. For instance, integers are
    objects since they are instances of the Fixnum class and have an
    object_id.

    Alex said everything is an object--including an instance of a class,
    the class itself, its methods. I agree up until he mention methods as
    objects. I don't think that can be demonstrated. For instance, we
    cannot get the object_id of a method. '+.object_id' doesn't work. So,
    I don't agree that methods are objects. Classes on the other hand, are
    instances of the Class class, and therefore, in a brain twisting way,
    are objects with object_ids.

    Demonstration:
    Monkey = Class.new

    #equivalent to
    #class Monkey; end

    Monkey.class # => Class
    Monkey.object_id # => 2159398000

    In addition to defining behavior, classes also can define state. The
    state is stored in instance variables. These concepts, defining the
    behavior and the state, are at the heart of object oriented
    programming.
    timr, Nov 11, 2010
    #5
  6. Eva

    Alex Stahl Guest

    [Note: parts of this message were removed to make it a legal post.]

    Method class: http://ruby-doc.org/core/classes/Method.html



    ________________________________________________________________________

    Alex Stahl | Sr. Quality Engineer | hi5 Networks, Inc. |
    |

    On Wed, 2010-11-10 at 23:55 -0600, timr wrote:

    > On Nov 10, 5:50 pm, Eva <> wrote:
    > > I'm also switching from perl and php.
    > > I'm not sure in ruby what's an object.
    > > It seems each instance of a class is an object, is it?
    > >
    > > Thanks.

    >
    > Classes are tables of defined behaviors (i.e. methods). An instance of
    > a class is indeed an object, as you noted. When a message is sent to
    > an object ("some string".upcase, "some string".reverse, "some
    > string".split('') etc.), the object looks inside the class that
    > instantiated it to see if it has the definition for that method. If
    > not it looks higher up the class ancestry chain to find the
    > definition. It may surprise you coming from perl and php that some
    > very basic things are objects in ruby. For instance, integers are
    > objects since they are instances of the Fixnum class and have an
    > object_id.
    >
    > Alex said everything is an object--including an instance of a class,
    > the class itself, its methods. I agree up until he mention methods as
    > objects. I don't think that can be demonstrated. For instance, we
    > cannot get the object_id of a method. '+.object_id' doesn't work. So,
    > I don't agree that methods are objects. Classes on the other hand, are
    > instances of the Class class, and therefore, in a brain twisting way,
    > are objects with object_ids.
    >
    > Demonstration:
    > Monkey = Class.new
    >
    > #equivalent to
    > #class Monkey; end
    >
    > Monkey.class # => Class
    > Monkey.object_id # => 2159398000
    >
    > In addition to defining behavior, classes also can define state. The
    > state is stored in instance variables. These concepts, defining the
    > behavior and the state, are at the heart of object oriented
    > programming.
    >
    Alex Stahl, Nov 11, 2010
    #6
  7. Eva

    Alex Stahl Guest

    [Note: parts of this message were removed to make it a legal post.]

    Not that I know the internals of the language well enough to debate the
    internal representation of a method, everything I've read suggests that,
    at a conceptual level, they can be regarded as such. Otherwise, how
    would we reconcile this description from the Method class link?
    (http://ruby-doc.org/core/classes/Method.html)

    meth == other_meth => true or false
    "Two method objects are equal if that are bound to the same object and
    contain the same body"

    Couldn't methods be considered specialized proc objects bound to a
    particular instantiation of an object? Also, there's this description
    at the link you provided:

    obj.method(sym) => method
    "Looks up the named method as a receiver in obj, returning a Method
    object (or raising NameError). The Method object acts as a closure in
    obj‘s object instance, so instance variables and the value of self
    remain available."


    ________________________________________________________________________

    Alex Stahl | Sr. Quality Engineer | hi5 Networks, Inc. |
    |

    On Wed, 2010-11-10 at 22:25 -0600, Y. NOBUOKA wrote:

    > > Simple answer: everything. Everything is considered an object,
    > > including an instance of a class, the class itself, its methods, etc.

    >
    > There is one thing incorrect.
    > In Ruby, an instance of a class or a class itself is exactly an object,
    > while a method is NOT an object.
    >
    > Although we can obtain a Method object using the *Object#method*
    > method [ http://ruby-doc.org/core/classes/Object.html#M000336 ], a
    > method itself is not an object.
    >
    Alex Stahl, Nov 11, 2010
    #7
  8. Eva

    Josh Cheek Guest

    [Note: parts of this message were removed to make it a legal post.]

    On Wed, Nov 10, 2010 at 10:25 PM, Y. NOBUOKA <>wrote:

    > > Simple answer: everything. Everything is considered an object,
    > > including an instance of a class, the class itself, its methods, etc.

    >
    > There is one thing incorrect.
    > In Ruby, an instance of a class or a class itself is exactly an object,
    > while a method is NOT an object.
    >
    > Although we can obtain a Method object using the *Object#method*
    > method [ http://ruby-doc.org/core/classes/Object.html#M000336 ], a
    > method itself is not an object.
    >
    >

    This seems self-contradictory, how is a method not an object?

    On Wed, Nov 10, 2010 at 11:55 PM, timr <> wrote:

    >
    > Alex said everything is an object--including an instance of a class,
    > the class itself, its methods. I agree up until he mention methods as
    > objects. I don't think that can be demonstrated. For instance, we
    > cannot get the object_id of a method. '+.object_id' doesn't work. So,
    > I don't agree that methods are objects.
    >
    >

    1.method('+').object_id
    Josh Cheek, Nov 11, 2010
    #8
  9. Eva

    Y. NOBUOKA Guest

    > Not that I know the internals of the language well enough to debate the
    > internal representation of a method, everything I've read suggests that,
    > at a conceptual level, they can be regarded as such. =A0Otherwise, how
    > would we reconcile this description from the Method class link?
    > (http://ruby-doc.org/core/classes/Method.html)
    >
    > meth =3D=3D other_meth =3D> true or false
    > "Two method objects are equal if that are bound to the same object and
    > contain the same body"
    >
    > Couldn't methods be considered specialized proc objects bound to a
    > particular instantiation of an object?


    A Method object (=3D an instance of the Method class) is an object. But
    it is not a method. It can be considered as a wrapper of the method
    which is bound to an object.

    We should think that a Method object is a thing that is different from
    a method.

    Please see also:
    http://stackoverflow.com/questions/2602340/methods-in-ruby-objects-or-not

    ---
    Methods are a fundamental part of Ruby's syntax, but they are not
    values that Ruby programs can operate on. That is, Ruby's methods are
    not objects in the way that strings, numbers, and arrays are. It is
    possible, however, to obtain a Method object that represents a given
    method, and we can invoke methods indirectly through Method objects.
    --- From "The Ruby Programming Language" [
    http://www.amazon.com/dp/0596516177/ ]

    --=20
    NOBUOKA Yuya
    Y. NOBUOKA, Nov 11, 2010
    #9
  10. On Thu, Nov 11, 2010 at 5:25 AM, Y. NOBUOKA <> wrot=
    e:
    >> Simple answer: =A0everything. =A0Everything is considered an object,
    >> including an instance of a class, the class itself, its methods, etc.

    >
    > There is one thing incorrect.
    > In Ruby, an instance of a class or a class itself is exactly an object,
    > while a method is NOT an object.
    >
    > Although we can obtain a Method object using the *Object#method*
    > method [ http://ruby-doc.org/core/classes/Object.html#M000336 ], a
    > method itself is not an object.


    I suggest a modification of Alex's definition:

    Everything /which can be referenced through a variable/ is considered an ob=
    ject.

    This includes classes, instances of Method etc. It's just that Method
    and subclasses are basically only proxies to the underlying
    implementation of a method - with limited functionality (obtaining
    arity and executing them for example). The mere fact that we obtain a
    new instance whenever we invoke #method hints at this:

    irb(main):005:0> s=3D""; 2.times.map { s.method:)length).object_id }
    =3D> [134981756, 134981742]

    Kind regards

    robert

    --=20
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Nov 11, 2010
    #10
  11. One other point. A local variable is not an object and never is -
    although you cam get an object which represents the stack frame it lives
    with (a Binding)

    --
    Posted via http://www.ruby-forum.com/.
    Brian Candler, Nov 11, 2010
    #11
  12. Eva

    Ammar Ali Guest

    On Thu, Nov 11, 2010 at 10:51 AM, Brian Candler <> wrote:
    > One other point. A local variable is not an object and never is -


    I think that's too general and confusing, at least to me.

    >> def m
    >> a = [1,2,3]
    >> p a.is_a?(Object)
    >> end

    => nil
    >> m

    true
    => true

    Is there more insight behind that statement? Or am I missing something
    fundamental?

    Thanks,
    Ammar
    Ammar Ali, Nov 11, 2010
    #12
  13. Eva

    Alex Stahl Guest

    [Note: parts of this message were removed to make it a legal post.]

    Fair enough. The link even cites the Ruby spec to indicate that
    methods, technically, are not/do not have to be an object.

    However, there is much to support that it is not at all a conceptual
    error to consider a method an object, even if the technical
    implementation is different.

    Consider that Ruby is a dynamically-typed language, frequently described
    as duck-typed. If a Method object has attributes, such as #arity and
    even #class, and methods like #call or #to_s, it sure looks like an
    object to me. Also consider that Ruby by design is intended not to get
    in the programmer's way, the way a language like PHP or Perl might,
    because of its dynamic features and flexibility.

    One does not need to know the internal details - such as "the 4th and
    5th paragraphs of Section 6.1 of the Ruby Language Specification (lines
    29-34 and 1-5 on pages 5 and 6)" - to be an effective programmer in
    Ruby. Does knowing those details give a programmer more options and a
    better understanding of the source-to-machine connection and the
    physical operation of their code? Absolutely. But does assuming that
    methods look like an object, and act like an object, and ignoring the
    underlying mechanisms (the black box effect), make a Ruby programmer
    less capable or likely to introduce bugs? Probably not.

    In fact, I would reference Russ Olsen's excellent "Design Patterns in
    Ruby" at this point. In Ch.2 of a very heavily abstracted, conceptual
    text (yet also quite practical, but I digress...), he states explicitly
    that everything is an object. He also says that, in the case of numeric
    assignment like 'x = 44', that "...x receives a reference to an object
    that happens to represent the number after 43." That seems to be
    remarkably similar to what happens in the case of the Method class,
    where the user doesn't really need to know what's going on, and can
    readily accomplish their task without concerning themselves with how 44
    is referenced or represented or how Method wraps a method.

    Great knowledge for interpreter hackers, but would assuming methods are
    objects and getting on with it be problematic? Would not knowing that
    subtraction is accomplished through addition also be problematic?

    I see there's some later posts now, so I'll hit send now.

    Regards,


    ________________________________________________________________________

    Alex Stahl | Sr. Quality Engineer | hi5 Networks, Inc. |
    |

    On Thu, 2010-11-11 at 01:51 -0600, Y. NOBUOKA wrote:

    > > Not that I know the internals of the language well enough to debate the
    > > internal representation of a method, everything I've read suggests that,
    > > at a conceptual level, they can be regarded as such. Otherwise, how
    > > would we reconcile this description from the Method class link?
    > > (http://ruby-doc.org/core/classes/Method.html)
    > >
    > > meth == other_meth => true or false
    > > "Two method objects are equal if that are bound to the same object and
    > > contain the same body"
    > >
    > > Couldn't methods be considered specialized proc objects bound to a
    > > particular instantiation of an object?

    >
    > A Method object (= an instance of the Method class) is an object. But
    > it is not a method. It can be considered as a wrapper of the method
    > which is bound to an object.
    >
    > We should think that a Method object is a thing that is different from
    > a method.
    >
    > Please see also:
    > http://stackoverflow.com/questions/2602340/methods-in-ruby-objects-or-not
    >
    > ---
    > Methods are a fundamental part of Ruby's syntax, but they are not
    > values that Ruby programs can operate on. That is, Ruby's methods are
    > not objects in the way that strings, numbers, and arrays are. It is
    > possible, however, to obtain a Method object that represents a given
    > method, and we can invoke methods indirectly through Method objects.
    > --- From "The Ruby Programming Language" [
    > http://www.amazon.com/dp/0596516177/ ]
    >
    Alex Stahl, Nov 11, 2010
    #13
  14. Eva

    Josh Cheek Guest

    [Note: parts of this message were removed to make it a legal post.]

    On Thu, Nov 11, 2010 at 2:59 AM, Ammar Ali <> wrote:

    > On Thu, Nov 11, 2010 at 10:51 AM, Brian Candler <>
    > wrote:
    > > One other point. A local variable is not an object and never is -

    >
    > I think that's too general and confusing, at least to me.
    >
    > >> def m
    > >> a = [1,2,3]
    > >> p a.is_a?(Object)
    > >> end

    > => nil
    > >> m

    > true
    > => true
    >
    > Is there more insight behind that statement? Or am I missing something
    > fundamental?
    >
    > Thanks,
    > Ammar
    >
    >

    I assume he means a itself, as opposed to the object that a is referencing.

    I personally think that most of these conversations end up pedantic and
    useless. I subscribe to Yehuda Katz's view that if a complicated mental
    model doesn't provide anything useful, it should not be used as an
    explanation
    http://yehudakatz.com/2010/02/25/rubys-implementation-does-not-define-its-semantics/
    Josh Cheek, Nov 11, 2010
    #14
  15. On Thu, Nov 11, 2010 at 9:51 AM, Brian Candler <> wrote:
    > One other point. A local variable is not an object and never is -
    > although you cam get an object which represents the stack frame it lives
    > with (a Binding)


    No variable ever *is* an object in Ruby. Variables *reference* objects!

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Nov 11, 2010
    #15
  16. Eva

    Ammar Ali Guest

    On Thu, Nov 11, 2010 at 11:20 AM, Josh Cheek <> wrote:
    > I assume he means a itself, as opposed to the object that a is referencing.


    I had a hunch, but that statement was too general and open to misinterpretation.

    > I personally think that most of these conversations end up pedantic and
    > useless.


    Even though I find some of these discussions useful to read, I agree
    that most end up pedantic and of little practical use for most.

    Regards,
    Ammar
    Ammar Ali, Nov 11, 2010
    #16
  17. Eva

    Ammar Ali Guest

    On Thu, Nov 11, 2010 at 11:27 AM, Robert Klemme
    <> wrote:
    > On Thu, Nov 11, 2010 at 9:51 AM, Brian Candler <> wrot=

    e:
    >> One other point. A local variable is not an object and never is -
    >> although you cam get an object which represents the stack frame it lives
    >> with (a Binding)

    >
    > No variable ever *is* an object in Ruby. =C2=A0Variables *reference* obje=

    cts!

    Now that's a different, or at least clearer, statement. And it fits
    with what I know.

    Thanks,
    Ammar
    Ammar Ali, Nov 11, 2010
    #17
  18. Eva

    Y. NOBUOKA Guest

    Did you recognize the difference between a method and a Method object?
    They are quite different. A Method object is a object which wrap a
    method that is bound to a specific object.

    > One does not need to know the internal details - such as "the 4th and
    > 5th paragraphs of Section 6.1 of the Ruby Language Specification (lines
    > 29-34 and 1-5 on pages 5 and 6)" - to be an effective programmer in
    > Ruby.


    Yes. I agree that one does not need to know the internal details.
    However, the difference between a Method object and a method is not
    the internal details.

    The relation between a method and a Method object in Ruby can be
    compared to the relation between a function and a structure which have
    a function pointer in C.

    --- in C
    /**
    * here define a structure which have a function pointer
    * this structure is equivalent to the Method class in Ruby
    */
    typedef struct {
    int (*pointer)( int arg );
    } Fuction;
    /**
    * here define a function to obtain a Function structure
    */
    Function *obtain_Function( int (*pointer)( int arg ) ) {
    Function *f = malloc( sizeof( Function ) );
    f->pointer = pointer;
    return f;
    }

    /* here is a function */
    int func( int arg ) {
    return arg * 2;
    }
    /* obtain the Function structure which wrap the function *func* */
    Function *func_obj = obtain_Function( func );
    ---

    --- in Ruby
    /* here is a method */
    def meth( arg )
    return arg * 2;
    end
    /* obtain the Method object which wrap the method *meth* */
    meth_obj = method( :meth )
    ---

    Can you recognize the difference between a method and a Method object?
    In C, the Function structure is exactly a structure, while the
    function *func* is not. In Ruby, similarly, the Method object is a
    object and the method *meth* is not.

    I think that Ruby users need not know how a Method object wraps a
    method, but they should know the fact that a Method object wraps a
    method and a method is not a object.

    Regards,

    --
    NOBUOKA Yuya
    Y. NOBUOKA, Nov 11, 2010
    #18
  19. Ammar Ali wrote in post #960710:
    >> No variable ever *is* an object in Ruby. =C2=A0Variables *reference* o=

    bjects!
    >
    > Now that's a different, or at least clearer, statement. And it fits
    > with what I know.


    Yes. It's important when you compare "pass by value" or "pass by =

    reference" in other languages. In ruby, everything is "pass by value", =

    and each value is a reference to an object - even integers.

    IMO this is a *huge* logical simplification over languages like perl =

    (scalar? array? array ref? list? hash? hash ref? filehandle? typeglob? =

    subroutine? Deal with them all differently)

    In ruby, a local variable is not an object, and as such you can never =

    obtain a "reference" to it.

    def foo(x)
    x << " world"
    end

    a =3D "hello"
    foo(a)

    a is passed by value, so the method call foo(a) can never affect the =

    value of a - it must remain pointing to the same object after the call. =

    However, if the object is mutable, it can cause it to change state =

    (using the << method in the example above)

    -- =

    Posted via http://www.ruby-forum.com/.=
    Brian Candler, Nov 11, 2010
    #19
  20. Eva

    Josh Cheek Guest

    [Note: parts of this message were removed to make it a legal post.]

    Disclaimer: I seem to be in a crabby mood this morning. I went back over it
    (twice) and tried to take out things that were unfriendly, sorry if I missed
    anything.

    On Thu, Nov 11, 2010 at 6:10 AM, Y. NOBUOKA <>wrote:

    > /* obtain the Function structure which wrap the function *func* */
    > Function *func_obj = obtain_Function( func );
    >


    That isn't what you do in Ruby. In Ruby, you don't pass the function (or
    function pointer in this case), you pass a String or Symbol.

    So this example is not consistent with what Ruby does, doesn't have any
    explanatory power (that I can see, though I don't write C extensions), and
    makes everything more complicated.

    Here is an alternative model: In Ruby, everything is an object. Methods are
    objects, hence the method class.
    http://ruby-doc.org/core/classes/Method.html But you can't directly access
    them, because Ruby doesn't make you use parentheses. So trying to access the
    method directly looks to the interpreter like you want to invoke the method,
    since that is pretty much always what you want to do. But every now and
    then, you want to actually get the method, and so Ruby gives you a getter
    method that knows how to do that, and it's aptly named "method".

    In C, that looks something like

    #include <stdio.h>
    #include <string.h>

    typedef struct {
    char* name;
    int (*pointer)( int arg );
    } Method;

    int twice( int arg ) { return arg * 2; }
    int thrice( int arg ) { return arg * 3; }

    Method internal_mlist[] = {
    { "twice" , twice },
    { "thrice" , thrice },
    };

    Method* method( char* name ) {
    int i;
    for( i = 0 ; i < sizeof(internal_mlist)/sizeof(Method) ; ++i )
    if( !strcmp( internal_mlist.name , name ) )
    return &internal_mlist;
    return NULL;
    }

    int main( ) {
    method("twice");
    method("thrice");
    return 0;
    }

    For a longer version that is more in line with my mental model
    https://gist.github.com/672665


    >
    > I think that Ruby users need not know how a Method object wraps a
    > method, but they should know the fact that a Method object wraps a
    > method and a method is not a object.
    >
    >

    Why? Is that even a Ruby thing? It seems so out of place to me that I would
    assume it is an MRI implementation detail. Do the other Rubies do it that
    way? If so, is it just for efficiency where they are all objects as soon as
    we need them to be, but keep it lazy and don't bother turning them into
    objects until such time as we know we need it?

    You guys were talking about a spec earlier, the site is apparently down
    right now, but I downloaded the source from github (
    https://github.com/rubyspec/rubyspec), trying to find something on this.
    Maybe I'm not looking in the right spot (I searched for /\.method[^_s]/) but
    I didn't see anything like this in there.



    On Thu, Nov 11, 2010 at 8:59 AM, Brian Candler <> wrote:

    >
    > Yes. It's important when you compare "pass by value" or "pass by
    > reference" in other languages. In ruby, everything is "pass by value",
    > and each value is a reference to an object - even integers.
    >
    >

    I think we settled on the phrase "object reference" last time this came up.
    Josh Cheek, Nov 11, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Parthiv Joshi
    Replies:
    2
    Views:
    670
    Kalyan
    Jul 2, 2004
  2. Suresh Kojhani
    Replies:
    1
    Views:
    2,362
    Anushi
    Jul 29, 2004
  3. Chris Fink
    Replies:
    2
    Views:
    4,063
    David Waz...
    Jul 3, 2003
  4. yysiow
    Replies:
    1
    Views:
    418
    Kevin Spencer
    Jul 12, 2003
  5. jon wayne
    Replies:
    9
    Views:
    695
    Jim Langston
    Sep 22, 2005
Loading...

Share This Page