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
Hi Amir,
2011/4/28 amir e. [email protected]:
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 ?
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.
(04/28/2011 06:48 PM), amir e. wrote:
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.”
On Thu, Apr 28, 2011 at 11:48 AM, amir e. [email protected] wrote:
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 + , - , * , ^ , ^^ isn’t
class Although they are primitive operation ?ps : If you test these codes , error happen : +.class -.class *.class
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
=> 3
irb(main):002:0> 1.+(2)
=> 3
irb(main):003:0> 1.send(“+”, 2)
=> 3
irb(main):004:0> 1.send(:+, 2)
=> 3
irb(main):005:0> 1.method “+”
=> #<Method: Fixnum#+>
Kind regards
robert
On Thu, Apr 28, 2011 at 08:52:35PM +0900, Josh C. wrote:
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.
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)”.
I might also have pointed out that punctuation marks aren’t objects,
either – like ., ", ;, and so on.
For my purposes at least, it seems perfectly consistent that methods
should not be objects, in any case. Methods aren’t things; they’re
techniques things use to get stuff done. They are what objects know,
rather than being objects themselves.
On Thu, Apr 28, 2011 at 4:48 AM, amir e. [email protected] wrote:
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.
2011/4/28 Chad P. [email protected]:
For my purposes at least, it seems perfectly consistent that methods
should not be objects, in any case. Methods aren’t things; they’re
techniques things use to get stuff done. They are what objects know,
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.
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 true in any language–and it is
irrelevant anyway. Whether everything is an object or just most things
doesn’t make a bit of difference in writing programs. First, you learn
the syntax of the language, and then you write programs. For instance,
in ruby, knowing whether a block is an object or not doesn’t affect
anything. You can pretend a block is an object and that it is passed as
an invisible parameter to a method, and it will make no difference at
all in how you program.
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 which trivial things
aren’t objects.
I think both of you are correct, in that:
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 = my_object.method( :a_method ) # returns a Method object bound to
my_object
m.call
Michael
Le 28 avr. 2011 à 11:26, Roger B. [email protected] a écrit :
On Fri, Apr 29, 2011 at 12:26:58AM +0900, Roger B. wrote:
easier.
Use callbacks for that. They work great.
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.
I don’t see this as a huge limitation.
BTW, having functions as objects is not really that unusual, see
Javascript.
JavaScript differs from Ruby in at least two ways that bear on this:
It uses a different object system abstraction from Ruby’s. It is
Ruby’s model for how objects work that informs my above-stated thoughts
on whether it is appropriate for methods to be objects themselves.
JavaScript depends on the ECMAScript standard, which is an obscene
mess. I don’t think it’s the world’s best example of how other
languages
should do things (especially class-based OOP languages, given the
prototype-based model of JavaScript). JavaScript could have been an
awesome language if not for the way the ECMA standards process ruined
it.
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
parenthesis
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.
~
On Thu, Apr 28, 2011 at 10:12 AM, Chad P. [email protected] wrote:
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 (
What's an object? - Ruby - Ruby-Forum). 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 +=
On Fri, Apr 29, 2011 at 02:23:32AM +0900, Josh C. wrote:
some examples:
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
. . . 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.
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:inmethod': undefined method&&’ for class `TrueClass’
(NameError)
Yeah – that’s because they aren’t methods. They’re more like
punctuation.
On Fri, Apr 29, 2011 at 01:54:20AM +0900, 7stud – wrote:
amir e. wrote in post #995492:
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.
It seems pretty unimportant until I try to interact with something as an
object and it turns out it isn’t an object.
Josh C. 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[b] and a[b] = 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
On Thu, Apr 28, 2011 at 10:22 PM, Brian C. [email protected]
wrote:
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 G.
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.
On Thu, Apr 28, 2011 at 3:22 PM, Chad P. [email protected] wrote:
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.
Chad P. wrote in post #995626:
On Fri, Apr 29, 2011 at 01:54:20AM +0900, 7stud – wrote:
amir e. wrote in post #995492:
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.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).send(:ancestors)
or maybe:
do |x|
puts x
end.call(3)
On Fri, Apr 29, 2011 at 08:50:49AM +0900, 7stud – wrote:
object and it turns out it isn’t an object.
Do you have a real world example of that? Perhaps:
(1, 2, 3).send(:ancestors)
puts.extend EnumerableOn Fri, Apr 29, 2011 at 08:39:14AM +0900, Josh C. wrote:
I think of operators as methods. Probably the best term for those is
predicate.
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.
. . . 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.
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)
It serves a purpose by helping you keep in mind that methods (techniques
for accomplishing tasks) are not the same as objects (things that “know”
those techniques).
. . . but, I guess, if you really want to think of them as objects, I’m
not going to stop you.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs