[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: How to do methodsoverloading in

Jeff Moore

7/30/2008 1:13:00 PM

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-....
11 Answers

Shadowfirebird

7/30/2008 1:45:00 PM

0

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
> 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-....
>
>



--
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

Phlip

7/30/2008 2:08:00 PM

0

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

Gregory Brown

7/30/2008 2:34:00 PM

0

On Wed, Jul 30, 2008 at 10:10 AM, Phlip <phlip2005@gmail.com> 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)
>> end
>> end
>> end
=> nil
>> a = Foo.new
=> #<Foo:0x5651a8>
>> a.foo(3,2)
=> 5
>> a.foo(:a => 3, :b => 2)
=> 5

-greg

Shadowfirebird

7/30/2008 2:35:00 PM

0

> 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...

Shadowfirebird

7/30/2008 2:39:00 PM

0

>> 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.

David A. Black

7/30/2008 2:47:00 PM

0

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

--
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.r... for details and updates!

Shadowfirebird

7/30/2008 3:25:00 PM

0

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 :-) 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
>
> --
> 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.r... 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

David A. Black

7/31/2008 11:08:00 AM

0

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:

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

--
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.r... for details and updates!

Jeff Moore

7/31/2008 1:59:00 PM

0

>
> 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-....

Florian Gilcher

7/31/2008 5:15:00 PM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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.

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.p...

(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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiR8yIACgkQJA/zY0IIRZa+2gCfdLRWDoU5ilJw4YsjVAz2Xhba
dX8AoKeB5KniAvpv8dM6KzPE27/6Auhk
=iRYG
-----END PGP SIGNATURE-----