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.
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 S. | Sr. Quality Engineer | hi5 Networks, Inc. | [email protected]
|
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 [ class Object - RDoc Documentation ], a
method itself is not an object.
2010/11/11 Alex S. [email protected]:
Simple answer: everything. Everything 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
object.
Class.class
=> Class
But Class is the instance of itself, I can’t understand for this. who
can help explain?
On Nov 10, 5:50pm, Eva [email protected] 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.
Method class: class Method - RDoc Documentation
Alex S. | Sr. Quality Engineer | hi5 Networks, Inc. | [email protected]
|
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?
(class Method - RDoc Documentation)
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 S. | Sr. Quality Engineer | hi5 Networks, Inc. | [email protected]
|
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:
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 P.ming Language” [
http://www.amazon.com/dp/0596516177/ ]
On Wed, Nov 10, 2010 at 10:25 PM, Y. NOBUOKA
[email protected]wrote:
This seems self-contradictory, how is a method not an object?
On Wed, Nov 10, 2010 at 11:55 PM, timr [email protected] 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
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)
On Thu, Nov 11, 2010 at 5:25 AM, Y. NOBUOKA [email protected]
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 [ class Object - RDoc Documentation ], 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
object.
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=“”; 2.times.map { s.method(:length).object_id }
=> [134981756, 134981742]
Kind regards
robert
On Thu, Nov 11, 2010 at 10:51 AM, Brian C. [email protected]
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
On Thu, Nov 11, 2010 at 2:59 AM, Ammar A. [email protected]
wrote:
=> nil
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 K.'s view that if a complicated mental
model doesn’t provide anything useful, it should not be used as an
explanation
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 S. | Sr. Quality Engineer | hi5 Networks, Inc. | [email protected]
|
On Thu, Nov 11, 2010 at 9:51 AM, Brian C. [email protected]
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
On Thu, Nov 11, 2010 at 11:27 AM, Robert K.
[email protected] wrote:
On Thu, Nov 11, 2010 at 9:51 AM, Brian C. [email protected] 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!
Now that’s a different, or at least clearer, statement. And it fits
with what I know.
Thanks,
Ammar
On Thu, Nov 11, 2010 at 11:20 AM, Josh C. [email protected]
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
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,
Ammar A. wrote in post #960710:
No variable ever is an object in Ruby. Variables reference objects!
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 = “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)
On Nov 11, 12:59am, Ammar A. [email protected] wrote:
m
true
=> trueIs there more insight behind that statement? Or am I missing something
fundamental?Thanks,
Ammar
When you ask object#is.a?(Class) you are asking if the Class is part
of the ancestry of the object. So you ask an array if it inherits
directly or indirectly from the Object class, and the answer is yes.
Here is a demo:
class New < String
end
=> nil
n = New.new
=> “”
n.is_a? New
=> true
n.is_a? String
=> true
n.is_a? Array
=> false
n.is_a? Object
=> true
New.ancestors
=> [New, String, Enumerable, Comparable, Object, Kernel]
But there is a distinction between inheriting from the Object class
and being an object. A better demonstration that the object like the
variable a points to in your example, is an instantiated object is to
ask it if it has an object_id–and it will. So the answer agrees with
the is_a? result, but the questions are asking very different things.
Tim