Sunny Bogawat wrote:
Hi,
ruby is object oriented language then how overloading is not possible in
ruby?
I want same method name with different parameters but it not work in
ruby?
def ovl(*a)
p a
end
ovl(99)
=> [99]
ovl('66')
=> ["66"]
ovl(99, '66')
=> [99, "66"]
ovl(66, '66',:parm1=>11, :parm2=> 33)
=> [66, "66", {:parm2=>33, :parm1=>11}]
def ovl2(a)
p a
end
ovl2(:parm1=>11, :parm2=> 33)
=> {:parm2=>33, :parm1=>11}
--
Posted via http://www.ruby-forum.com/\.
I think I'm right in saying that a OOP does not require method overloading?
It's not needed for inheritance.
It's not needed for polymorphism.
Whether it's *useful*, or just confusing (or both!) is another thing
entirely. I'm not experienced enough in OOP to express an opinion.
The author of the language obviously has an opinion, though: Ruby
allows you to redefine operators, but you can't have multiple
definitions of the same method in the same class.
Given that Ruby is typeless, I'm not sure how it would be otherwise.
On Wed, Jul 30, 2008 at 2:13 PM, Jeff Moore <jcmoore@pressenter.com> wrote:
Sunny Bogawat wrote:
Hi,
ruby is object oriented language then how overloading is not possible in
ruby?
I want same method name with different parameters but it not work in
ruby?def ovl(*a)
p a
endovl(99)
=> [99]ovl('66')
=> ["66"]ovl(99, '66')
=> [99, "66"]ovl(66, '66',:parm1=>11, :parm2=> 33)
=> [66, "66", {:parm2=>33, :parm1=>11}]def ovl2(a)
p a
endovl2(:parm1=>11, :parm2=> 33)
=> {:parm2=>33, :parm1=>11}
--
Posted via http://www.ruby-forum.com/\.
--
Me, I imagine places that I have never seen / The colored lights in
fountains, blue and green / And I imagine places that I will never go
/ Behind these clouds that hang here dark and low
But it's there when I'm holding you / There when I'm sleeping too /
There when there's nothing left of me / Hanging out behind the
burned-out factories / Out of reach but leading me / Into the
beautiful sea
Shadowfirebird wrote:
I think I'm right in saying that a OOP does not require method overloading?
It's not needed for inheritance.
It's not needed for polymorphism.
How do you polymorph without overloading a method?
There are those who define OO _as_ using overloaded (virtual, polymorphic) methods to decouple things. For example, the OS method open() could open a file or a device like a printer. The behavior of write() polymorphs.
The author of the language obviously has an opinion, though: Ruby
allows you to redefine operators, but you can't have multiple
definitions of the same method in the same class.Given that Ruby is typeless, I'm not sure how it would be otherwise.
Ruby is strongly typed, dynamic, and extensible, permitting Monkey Patching.
For example, just yesterday we needed the Rails number_to_currency method to implement its :negative_parens option. That's not published yet, so we looked up its patch and pasted it into our code directly. Problem solved - and note this is a kind of polymorph. You can't have the old method back, though!
--
Phlip
Given that Ruby is typeless, I'm not sure how it would be otherwise.
Ruby is strongly typed, dynamic, and extensible, permitting Monkey Patching.
For example, just yesterday we needed the Rails number_to_currency method to
implement its :negative_parens option. That's not published yet, so we
looked up its patch and pasted it into our code directly. Problem solved -
and note this is a kind of polymorph. You can't have the old method back,
though!
Granted you can't literally get the method back but if you use *args
and alias_method effectively, you can avoid changing the signature of
the original method and revert back to it for the things your patch
doesn't cover. Of course, in the case you mentioned, if the support
for that option was midstream in the method, you might be out of luck.
class Foo
def foo(a,b)
a + b
end
alias_method :original_foo, :foo
def foo(*args)
if Hash === args[0]
original_foo(args[0][:a], args[0][:b])
else
?> original_foo(*args)
end
end
end
=> nil
a = Foo.new
=> #<Foo:0x5651a8>
a.foo(3,2)
=> 5
a.foo(:a => 3, :b => 2)
=> 5
-greg
On Wed, Jul 30, 2008 at 10:10 AM, Phlip <phlip2005@gmail.com> wrote:
How do you polymorph without overloading a method?
Well, okay. I was taking overloading to mean, defining two methods
with the same name (but different signatures) *in the same class*.
And I hope you will agree that you don't need to do *that* to
polymorph.
(A quick "google define" seems to bear me out on this, BTW, but by all
means let us agree to have slightly different definitions of some
words. I'm with Humpty-Dumpty on this.)
class Root
...
def me; puts "I'm a Root"; end
end
class One < Root
...
def me; puts "I'm a One"; end
end
class Two < Root
...
def me; puts "I'm a Two"; end
end
...and there you go; polymorphism in Ruby. At least, in my naieve
understanding...
Given that Ruby is typeless, I'm not sure how it would be otherwise.
Ruby is strongly typed, dynamic, and extensible, permitting Monkey Patching.
Okay, *there* you caught me. I was grossly oversimplifying.
What I should have said was, Ruby isn't *statically* typed. Which
means that it can't use a parameter signature to tell different method
definitions with the same name apart. At least, so I understand is
the received wisdom -- I imagine only Matz could say for sure.
Hi --
Given that Ruby is typeless, I'm not sure how it would be otherwise.
Ruby is strongly typed, dynamic, and extensible, permitting Monkey Patching.
Okay, *there* you caught me. I was grossly oversimplifying.
Not grossly 
Type in Ruby is kind of a tautology: an object's type
is the type "the type of objects which are of this type." In the end,
the notion of type kind of cancels itself out (or gets replaced by the
notion of class, which it doesn't actually correspond to and which
causes a lot of problems).
What I should have said was, Ruby isn't *statically* typed. Which
means that it can't use a parameter signature to tell different method
definitions with the same name apart. At least, so I understand is
the received wisdom -- I imagine only Matz could say for sure.
People have written lots of libraries that try to examine method
signatures, if not statically, then dynamically but in such a way that
things will fail if the method is called with the wrong arguments.
"Wrong," however, is almost always defined as "of the 'wrong' class",
which of course doesn't play very nicely with the fact that Ruby
objects have more on their minds than what class gave birth to them.
There have been more elaborate attempts to check for type, rather than
class, and some have been very interesting and educational; but they
always end up feeling like a kind of second skin on top of what Ruby
already does.
David
On Wed, 30 Jul 2008, Shadowfirebird wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
I must admit that I love Ruby because it manages to combine brevity
with readability (quite a trick!).
But the brevity sort of goes out the window if every method has to
paranoidly check the class of every parameter passed to it. It's a bit
of a pain. But so is the alternative.
I gather from what David says that there's no magic bullet...?
On Wed, Jul 30, 2008 at 3:46 PM, David A. Black <dblack@rubypal.com> wrote:
Hi --
On Wed, 30 Jul 2008, Shadowfirebird wrote:
Given that Ruby is typeless, I'm not sure how it would be otherwise.
Ruby is strongly typed, dynamic, and extensible, permitting Monkey
Patching.Okay, *there* you caught me. I was grossly oversimplifying.
Not grossly
is the type "the type of objects which are of this type." In the end,
the notion of type kind of cancels itself out (or gets replaced by the
notion of class, which it doesn't actually correspond to and which
causes a lot of problems).What I should have said was, Ruby isn't *statically* typed. Which
means that it can't use a parameter signature to tell different method
definitions with the same name apart. At least, so I understand is
the received wisdom -- I imagine only Matz could say for sure.People have written lots of libraries that try to examine method
signatures, if not statically, then dynamically but in such a way that
things will fail if the method is called with the wrong arguments.
"Wrong," however, is almost always defined as "of the 'wrong' class",
which of course doesn't play very nicely with the fact that Ruby
objects have more on their minds than what class gave birth to them.There have been more elaborate attempts to check for type, rather than
class, and some have been very interesting and educational; but they
always end up feeling like a kind of second skin on top of what Ruby
already does.David
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
--
Me, I imagine places that I have never seen / The colored lights in
fountains, blue and green / And I imagine places that I will never go
/ Behind these clouds that hang here dark and low
But it's there when I'm holding you / There when I'm sleeping too /
There when there's nothing left of me / Hanging out behind the
burned-out factories / Out of reach but leading me / Into the
beautiful sea
Hi --
I must admit that I love Ruby because it manages to combine brevity
with readability (quite a trick!).
I agree.
But the brevity sort of goes out the window if every method has to
paranoidly check the class of every parameter passed to it. It's a bit
of a pain. But so is the alternative.I gather from what David says that there's no magic bullet...?
There are two reasons not to check the class of every parameter:
1. It doesn't work, because objects aren't limited to the behavior
defined in their classes.
2. It stops you from thinking more flexibly about how to leverage
the power of Ruby objects, rather than smothering it.
David
On Thu, 31 Jul 2008, Shadowfirebird wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
But why does it have to? Why should it?
http://talklikeaduck.denhaven2.com/articles/2007/10/22/chicken-typing-isnt-duck-typing
On Wed, Jul 30, 2008 at 11:24 AM, Shadowfirebird <shadowfirebird@gmail.com>wrote:
I must admit that I love Ruby because it manages to combine brevity
with readability (quite a trick!).But the brevity sort of goes out the window if every method has to
paranoidly check the class of every parameter passed to it.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
There are two reasons not to check the class of every parameter:
1. It doesn't work, because objects aren't limited to the behavior
defined in their classes.
2. It stops you from thinking more flexibly about how to leverage
the power of Ruby objects, rather than smothering it.David
I know I'll take clarity, convenience and expedience over theoretical
benefits
*every single time*
Ruby is the axe I've been looking for for quite a while
Regards
--
Posted via http://www.ruby-forum.com/\.
I really liked you talk at EuRuKo about that topic which illustrated quite
well why "type" is a convention that should not be overused in a
dynamic language.
For this interested, it should be available here:
http://www.avc-cvut.cz/avc.php?id=6882
(offline at the moment, i contacted the EuRuKo-guys)
But I do think that splitting methods into clauses depending on argument
patterns is a thing thats really missing in ruby (or most OO-languages), because
it solves the problem of not being able to change behaviour of proxy methods
without reimplementing the whole method.
Be aware that I am talking about arbitrary patterns here, not type patterns. [1]
Regards,
Florian Gilcher
[1] For those of you that where at the EuRuKo 2008 and heard my talk: my library
accomplishing this task is not ready at the moment because i have absolutely no time.
If someone is interested in code that is in alpha state, drop me a line.
On Jul 31, 2008, at 1:08 PM, David A. Black wrote:
Hi --
But the brevity sort of goes out the window if every method has to
paranoidly check the class of every parameter passed to it. It's a bit
of a pain. But so is the alternative.I gather from what David says that there's no magic bullet...?
There are two reasons not to check the class of every parameter:
1. It doesn't work, because objects aren't limited to the behavior
defined in their classes.
2. It stops you from thinking more flexibly about how to leverage
the power of Ruby objects, rather than smothering it.