what's an object?

[Eva]

SSdtIGFsc28gc3dpdGNoaW5nIGZyb20gcGVybCBhbmQgcGhwLgpJJ20gbm90IHN1cmUgaW4gcnVi
eSB3aGF0J3MgYW4gb2JqZWN0LgpJdCBzZWVtcyBlYWNoIGluc3RhbmNlIG9mIGEgY2xhc3MgaXMg
YW4gb2JqZWN0LCBpcyBpdD8KClRoYW5rcy4K

 

[Alex Stahl]

[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. | (e-mail address removed)
|

 

[Y. NOBUOKA]

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.

 

[zuerrong]

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)

 

[timr]

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]

[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. | (e-mail address removed)
|

 

[Alex Stahl]

[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. | (e-mail address removed)
|

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.

 

[Josh Cheek]

[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.

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?

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

 

[Y. NOBUOKA]

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

 

[Robert Klemme]

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.methodlength).object_id }
=3D> [134981756, 134981742]

Kind regards

robert

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

 

[Brian Candler]

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)

 

[Ammar Ali]

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

 

[Alex Stahl]

[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. | (e-mail address removed)
|

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/ ]

 

[Josh Cheek]

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

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/

 

[Robert Klemme]

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

 

[Ammar Ali]

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]

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

 

[Y. NOBUOKA]

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,

 

[Brian Candler]

Ammar Ali wrote in post #960710:

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

 

[Josh Cheek]

[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.

/* 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.

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.