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?
Sunny B. 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}
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!
On Wed, Jul 30, 2008 at 10:10 AM, Phlip [email protected] 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.
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)endend
end
=> nila = Foo.new
=> #Foo:0x5651a8a.foo(3,2)
=> 5a.foo(:a => 3, :b => 2)
=> 5
-greg
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 M. [email protected]
wrote:
end
ovl(66, ‘66’,:parm1=>11, :parm2=> 33)
–
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
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 –
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 
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
Hi –
On Thu, 31 Jul 2008, Shadowfirebird wrote:
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:
- It doesn’t work, because objects aren’t limited to the behavior
defined in their classes. - It stops you from thinking more flexibly about how to leverage
the power of Ruby objects, rather than smothering it.
David
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 [email protected]
wrote:
Okay, there you caught me. I was grossly oversimplifying.
the received wisdom – I imagine only Matz could say for sure.
always end up feeling like a kind of second skin on top of what Ruby
–
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jul 31, 2008, at 1:08 PM, David A. Black wrote:
There are two reasons not to check the class of every parameter:
- It doesn’t work, because objects aren’t limited to the behavior
defined in their classes.- It stops you from thinking more flexibly about how to leverage
the power of Ruby objects, rather than smothering it.
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 G.
[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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkiR8yIACgkQJA/zY0IIRZa+2gCfdLRWDoU5ilJw4YsjVAz2Xhba
dX8AoKeB5KniAvpv8dM6KzPE27/6Auhk
=iRYG
-----END PGP SIGNATURE-----
On Wed, Jul 30, 2008 at 11:24 AM, Shadowfirebird
[email protected]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.
But why does it have to? Why should it?
http://talklikeaduck.denhaven2.com/articles/2007/10/22/chicken-typing-isnt-duck-typing
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
There are two reasons not to check the class of every parameter:
- It doesn’t work, because objects aren’t limited to the behavior
defined in their classes.- 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