Is everything object ?

[amir e.]

Hi
A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.
Now if every thing is object , then why + , - , * , ^ , ^^ isn't
class Although they are primitive operation ?

ps : If you test these codes , error happen : +.class -.class *.class

 

[Roger Braun]

Hi Amir,

Hi
A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.
Now if every thing is object , then why =C2=A0 + , - , * , ^ , ^^ =C2=A0 = isn't
class Although they are primitive operation ?

Methods always belong to a class in Ruby, but they are NOT objects (I
hope this will change some day, maybe Ruby 2.0?). You can make
method-like objects (procs or lambdas), though.

--=20
Roger Braun
rbraun.net | humoralpathologie.de

 

[Urabe Shyouhei]

Hi
A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.
Now if every thing is object , then why + , - , * , ^ , ^^ isn't
class Although they are primitive operation ?

ps : If you test these codes , error happen : +.class -.class *.class

“Or else it doesn't, you know. The name of the song is called ‘Haddocks' Eyes.’â€

“Oh, that's the name of the song, is it?" Alice said, trying to feel interested.

“No, you don't understand,†the Knight said, looking a little vexed. “That's
what the name is called. The name really is ‘The Aged Aged Man.’â€

“Then I ought to have said ‘That's what the song is called’?†Alice corrected
herself.

“No, you oughtn't: that's quite another thing! The song is called ‘Ways And
Means’: but that's only what it's called, you know!â€

“Well, what is the song, then?†said Alice, who was by this time completely
bewildered.

“I was coming to that,†the Knight said. “The song really is ‘A-sitting On A
Gate’: and the tune's my own invention.â€

 

[Robert Klemme]

A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.

That wording does not really make sense. You probably mean that every
operator is a method, do you?

Now if every thing is object , then why =A0 + , - , * , ^ , ^^ =A0 isn't
class Although they are primitive operation ?

ps : If you test these codes , error happen : +.class =A0-.class =A0 *.cl=

ass

I am not 100% sure what you are up to but in case you wonder whether
"+" is not something tangible (i.e. an object) this might explain:
operators (+, - etc.) are mainly syntactic sugar for method calls and
you can actually invoke them like methods:

irb(main):001:0> 1 + 2
=3D> 3
irb(main):002:0> 1.+(2)
=3D> 3
irb(main):003:0> 1.send("+", 2)
=3D> 3
irb(main):004:0> 1.send+, 2)
=3D> 3
irb(main):005:0> 1.method "+"
=3D> #<Method: Fixnum#+>

Kind regards

robert

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

 

[Josh Cheek]

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

Hi
A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.
Now if every thing is object , then why + , - , * , ^ , ^^ isn't
class Although they are primitive operation ?

ps : If you test these codes , error happen : +.class -.class *.class

Those are methods, the Ruby interpreter uses syntactic sugar to make them
look like operators.

1.methods.grep(/^[\W]/) # => [:-@, :+, :-, :*, :/, :%, :**, :==, :===, :<=>,
:>, :>=, :<, :<=, :~, :&, :|, :^, :[], :<<, :>>, :+@, :=~, :!~, :!, :!=]

(the leading colons means these are symbols, if you aren't familiar with
symbols, you can think of them as a slightly different type of string)



There are only three _relevant_ things that I can think of right now that
aren't objects. Let us say that a thing is relevant as a nonobject if it
means you can't manipulate it like an object (ie pass it as an argument,
store it in a variable, and call methods on it). The first is boolean
methods like "&&" and "||", the second is keywords like "class", and "def",
the third is variables, which point to objects but are not objects
themselves, thus cannot be pointed to by other variables.

Using my above definition of "relevant", it is *not* relevant that methods
and blocks aren't objects (in MRI), and I think it is better for your mental
health and your understanding of the language if you forget that particular
piece of pedantic trivia.

 

[Roger Braun]

For my purposes at least, it seems perfectly consistent that methods
should not be objects, in any case. =C2=A0Methods aren't *things*; they'r= e
techniques *things* use to get stuff done. =C2=A0They are what objects kn= ow,
rather than being objects themselves.

I can not completely agree with that. One reason why methods should be
objects is because it is great to treat them like this (as the
quasi-method-object called "block" proves) and makes a lot of stuff
easier. Also, you can only bind objects to variables in Ruby, nothing
else. So if I want to use a method in several places that don't know
the method name beforehand, I have to wrap the method in a Proc
object.
BTW, having functions as objects is not really that unusual, see Javascript=

 

[Michael Sokol]

I think both of you are correct, in that:

- Object are tangible things capable of processing -> composed of methods
Thus an object isn't an entity that aggregate other entities (method objects=
). It's a closed, encapsulated, independent thing.

However, it'd make sense to treat method as first-class objects. A method is=
only a procedure bound to an instance. In fact, Ruby allows you to do that:=


m =3D my_object.method( :a_method ) # returns a Method object bound to my_ob=
ject
m.call

Michael

 

[7stud --]

amir e. wrote in post #995492:

Hi
A very important principle in Ruby is that every thing is object.

I have never found that claim to be important in any language. Whether
everything is an object or just most things doesn't make a bit of
difference in writing programs. Now if you were selected to be on a
Ruby Trivia Show, and you can win thousands of $$$, then it would be
helpful to know.

 

[Josh Cheek]

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

I'm a little curious about why, to you, boolean methods are "relevant"
and other methods are not. For that explanation, I would have just said
that methods are not objects -- rather than saying something like
"boolean methods aren't objects; let's not talk about other methods
(which also aren't, but we shouldn't say that)".

Sorry, I wasn't very clear, it's a difficult subject to talk about because
the language is largely ambiguous.

Apparently, methods are *technically* not objects. Roger already brought it
up above, and it's been discussed before (
http://www.ruby-forum.com/topic/424911). Now, given that we can request a
method, and get an instance of Method, lets disregard this as it seems to me
to be an implementation detail.

So we can say that methods are objects, and everything suddenly makes sense
again. Operators are methods, and methods are objects, so operators are
objects. Except for boolean operators, which are not methods and thus not
objects. They are basically keywords. Here are some examples:


You can't define || or && on your object.
class Foo
def &(other)
"foo and #{other}"
end
end
Foo.new & 'bar' # => "foo and bar"

class Foo
def &&(other)
"foo and and #{other}"
end
end
Foo.new && 'bar' # ~> -:9: syntax error




You can't request them as methods, and thus can't pass them as arguments or
put them into block slots or store them in variables.
true.method '&' # => #<Method: TrueClass#&>
true.method '&&' # ~> -:1:in `method': undefined method `&&' for class
`TrueClass' (NameError)



With normal operators you can do fun stuff like this
plus_ten = 10.method('+')
[1,2,3,4,5].map(&plus_ten) # => [11, 12, 13, 14, 15]
But you can't do anything like that with &&, because it's not a method.




I was thinking about it just now, and realized assignment methods are the
same way. For example, you can't define +=

 

[Stu]

Everything is a sender and receiver in ruby. The operators you list
are methods tied to the classes they work on. This is known as
polymorphism.

ex:

4 + 6
is
4.+( 6)
see Object dot method with argument (can be read 4.add(6) )
Ruby has a way where the interpreter will work without the dot and parenthe=
sis

Where the polymorphic design of the language comes in is the
redefinition of + for other class types such as strings and
collections. for a string it will concatenate:

"Hello, " + " world!"
is
string.concat(string)
observe this in irb as well:
"Hello, ".+("world")
String.new("Hello, ").+("world")

These are all equivalent.

last example:
[42,17,3.14] + [999]
is
Array.new( [42,17,3.14]).+( [999])

So essentially the primitive operations as you word it are really
complex and cleverly designed methods provided to give the illusion of
they are primitive. They are methods in ruby. redefined in each
respective class to provide the proper abstraction on the type of data
the operands are dealing with.

If this may give you a better perspective on your question let's break
the interpreter. Type this in irb:

class Fixnum
def +(arg)
42
end
end

now running any addition will result with the number 42.

Of course you don't want to mess with the numerical classes but when
you go on to write your own classes it may come in handy to redefine
these operand methods within those classes to aid in the classes
abstraction.

~

 

[Brian Candler]

Josh Cheek wrote in post #995509:

There are only three _relevant_ things that I can think of right now
that
aren't objects. Let us say that a thing is relevant as a nonobject if it
means you can't manipulate it like an object (ie pass it as an argument,
store it in a variable, and call methods on it). The first is boolean
methods like "&&" and "||", the second is keywords like "class", and
"def",
the third is variables, which point to objects but are not objects
themselves, thus cannot be pointed to by other variables.

I think it's reasonable to say that most operators in Ruby are in fact
syntactic sugar for method calls; so are some other syntactic
constructions like a and a = c. All these can be invoked
equivalently using send, e.g.

a.send[]=, b, c)

However the assignment operators =, +=, -= etc are *not* mapped to
method calls, in addition to the short-circuit boolean operators as
you've already pointed out.

It's perhaps also worth mentioning that literals don't invoke method
calls; e.g. "foo" and /foo/ can't be intercepted by redefining
String.new or Regexp.new

 

[Phillip Gawlowski]

However the assignment operators =, +=, -= etc are *not* mapped to
method calls, in addition to the short-circuit boolean operators as
you've already pointed out.

But they are syntactic sugar for the syntactic sugar (except for "=",
which is probably better seen as a keyword):

a += b expands to a = a + b.

--
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.

 

[Josh Cheek]

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

Oh, you're talking about boolean operators. I thought you were talking
about actual boolean *methods*:

irb(main):001:0> foo = Hash.new
=> {}
irb(main):002:0> foo.empty?
=> true

I think of operators as methods. Probably the best term for those is
predicate.

. . . but I dispute the argument you present that methods are objects.
The fact that one can wrap a method in a "method object" does not make
the method *itself* an object; it just creates an object that has a
particular kind of interface to the method.

I'm not saying that methods are objects, I'm saying that calling them
non-objects serves no purpose, and choosing to think of them as objects (as
Ruby obviously wants you to) allows Ruby to be elegant again.

 

[7stud --]

Chad Perrin wrote in post #995626:

It seems pretty unimportant until I try to interact with something as an
object and it turns out it *isn't* an object.

Do you have a real world example of that? Perhaps:

(1, 2, 3).sendancestors)

 

[Josh Cheek]

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

Thinking of them as methods is probably a bad idea. It may lead you to
make unwarranted assumptions about things you can do with them.

Can you be more explicit? They are methods, I don't understand what you
mean.

It's perfectly "elegant" in terms of a consistent model without
mislabeling methods as objects. Ruby does not seem to "want" me to think
of methods as objects, else stuff like this would be meaningful

puts.extend Enumerable
puts.class
foo(puts)

Those are meaningful, if you are interested in what the method returns
(nil). If you are interested in the method, then don't invoke it. Since
listing the method's name is syntactic sugar for invoking it, then how do
you get the method? Just ask for it methodputs).extend(Enumerable)

puts.extend Enumerable

That, of course works, puts evalutaes to nil, nil is an object and therefore
has a singleton class, and therefore can be extended.

puts # => nil
puts.singleton_class.ancestors # => [NilClass, Object, Kernel, BasicObject]
puts.extend Enumerable
puts.singleton_class.ancestors # => [NilClass, Enumerable, Object, Kernel,
BasicObject]

 

[Justin Collins]

Hi
A very important principle in Ruby is that every thing is object.
I read somewhere that there is no primitive operation in Ruby in
traditional form and every operation is class.
Now if every thing is object , then why + , - , * , ^ , ^^ isn't
class Although they are primitive operation ?

ps : If you test these codes , error happen : +.class -.class *.class

Actually, "everything is an object" is probably a mantra Rubyists should
drop, because people will get confused when they find they can't call
methods on every piece of Ruby code.

I would say all values in Ruby are objects and all expressions return a
value. But there are (admittedly few) things which are not expressions.

The best thing is to not worry too much about absolutes and just enjoy
exploring.

-Justin

 

[Josh Cheek]

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

It doesn't extend puts; puts is not an object. Trying to think of puts
as an object doesn't work. It gives surprising results if you actually
expect it to behave as an object in and of itself, thus violating the
"objects and methods" model of Ruby.

That's because methods are invoked by default, as I already stated. You need
a line that evaluates to the method, not to nil. Your issue isn't with the
objectivity of methods, it is with how you access methods.

# this is evaluated
puts # => nil

# now we have a reference to it
puts = method uts # => #<Method: Object(Kernel)#puts>

# and look, we can extend it
puts.extend Enumerable # => #<Method: Object(Kernel)#puts>
puts.singleton_class.ancestors # => [Enumerable, Method, Object, Kernel,
BasicObject]

 

[Josh Cheek]

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

That's a wrapper -- not the method itself.

A little elaboration . . .

class String
def end_upcase
self.split[-1].upcase # This Line: Method
end
end

'foo bar baz'.end_upcase # String Before Dot: Object Literal
# Thing After Dot: Message

The string of characters "end_upcase" in the above isn't even a method,
per se; it's a message, sent to the object that is the return value of
the expression preceding it. The return value of an object literal is
the object literal. The return value of a nonliteral object is the
object reference stored under whatever label/variable you use for it, or
the object that is returned by some other form of expression.

So . . . it is not only the case that methods are not objects; it is also
the case that the thing you probably think of as a method is not a
method. It's a message, being sent to an object, which in turn probably
has a method defining how it responds to that message.

I like that distinction, the message is :end_upcase, and the method is the
code that is invoked. But I still think that considering the method itself
to be a nonobject has no explanatory value (unless maybe you're knee deep in
C), and requires lots of confusing explanations for it to make sense.

IOW, the model is message passing, and when the message is received, it
invokes the method. To get the method then, we must tell the interpreter,
that we want the method that would be invoked by this message, and it
returns it to us. I think that explains the behaviour quite nicely. Is there
a model which involves non object methods, which explains something that
this does not, and does not involve completely invisible complications?

 

[Michael Sokol]

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

I like Chad's explanation.

I'd like to add that by definition, an object is a state and a behavior. In the case of a method object, it surely has a behavior, but I would question its state.

 

[Duke Normandin]

I like Chad's explanation.

I'd like to add that by definition, an object is a state and a
behavior. In the case of a method object, it surely has a behavior,
but I would question its state.

I've dabbled with Smalltalk and Self, and so his explanations of the
way Ruby operates remind me _a lot_ of how the former languages work.