Asp Forum - Re: Injecting methods from one class into another.

e

1/25/2005 10:52:00 PM

> Lähettäjä: "George Moschovitis" <george.moschovitis@gmail.com>
> Aihe: Re: Injecting methods from one class into another.
>
> > I do not think what you want has anything to do with 'duck typing'.
>
> Of course it has. Have a look at the following example:
>
> class C1
> attr_accessor :a
>
> def a1
> puts @a
> end
>
> def a2
> puts 'hello'
> end
> end
>
> class C2
> attr_accessor :a
> end
>
> So for method C1#a1 the class C2 'quacks like a duck' (ie, it has the
> attribute @a)
>
> So in 'duck typing' spirit, it should be possible to do:
>
> c = C2.new
>
> m = C1.instance_method(:a1)
> m.bind(c)
>
> c.a1
>
> however Ruby raises a TypeError :(

You're forgetting something. It's not "If it quacks...", it's
"If it quacks... and if it walks...". The gist is that as long as
an object has *all* of the (required) characteristics of a type, the
object can be treated as a specimen of that type.

As an animal analogy regarding 'injecting' methods, tearing off the
wings of a duck and gluing them to a pig doesn't mean the pig can fly.

> Can anyone give me an example, where this #bind method is usefull? I
> mean, you can only bind a Method back to an object of the original
> method's Class or a Subclass. But such an object allready has this
> method, so whats the point?
> Am I missing something here?
>
> regards,
> George

E

6 Answers

Sam Roberts

1/26/2005 2:49:00 AM

Quoteing eero.saynatkari@kolumbus.fi, on Wed, Jan 26, 2005 at 07:51:57AM +0900:
> > Lähettäjä: "George Moschovitis" <george.moschovitis@gmail.com>
> > Aihe: Re: Injecting methods from one class into another.
> >
> > > I do not think what you want has anything to do with 'duck typing'.
> You're forgetting something. It's not "If it quacks...", it's
> "If it quacks... and if it walks...". The gist is that as long as
> an object has *all* of the (required) characteristics of a type, the
> object can be treated as a specimen of that type.

I don't think thats the case at all. I'd like to see you implement
something that "walks like a Hash" by your definition! Make sure you
do all of:

==, [], []=, clear, default, default=, default_proc, delete,
delete_if, each, each_key, each_pair, each_value, empty?, fetch,
has_key?, has_value?, include?, index, indexes, indices,
initialize_copy, inspect, invert, key?, keys, length, member?,
merge, merge!, rehash, reject, reject!, replace, select, shift,
size, sort, store, to_a, to_hash, to_s, update, value?, values,
values_at

And there is no "HashWalk" module you can include to make your class
walk like a Hash, so you might have to copy all those methods...

Yet, there are many objects that are sufficiently like a Hash that you
can use that object in place of a Hash, in particular circumstances. I'd
say that's the more common use of duck-typing.

> As an animal analogy regarding 'injecting' methods, tearing off the
> wings of a duck and gluing them to a pig doesn't mean the pig can fly.

There are methods in library classes I would like in my classes. Right
now, I cut and paste. Yes, if those methods were in a module, I could
include them, but they are not. Would "method stealing" always work? Of
course not. But, the methods I want would work!

This is a real example, the specific methods I have copied are from
resolv.rb, DNS#getaddress() ... DNS#getresources() I have copied (I have
my own #each_resource()).

I may try to inherit. But, my class relationship to DNS does NOT model
a "is a" relationship. So, I am abusing inheritance to steal
implementation. Is this so beautiful?

Also, there are methods I don't want, I need to make sure they do not
appear. Also, there are constants that must have a different value in my
class, can I change them? I don't think so.

Really, I just want those methods! But, there is no way to get them in
my class other than copying, or convincing the maintainer to cut his
class into pieces for me. Too bad.

Ruby is still better than the alternatives.

Thanks,
Sam

George Moschovitis

1/26/2005 9:22:00 AM

> You're forgetting something. It's not "If it quacks...", it's
> "If it quacks... and if it walks...".

not really!

The method I want to inject ONLY cares for quacking, NOT walking, so
for this method, an object that quacks IS a Duck.

The same happens with Ruby's to_s:

Array (~Hawk) implements to_s, so for puts it is a String (~Duck)
George.

-g.

dblack

1/26/2005 12:25:00 PM

Florian Gross

1/26/2005 12:55:00 PM

David A. Black wrote:

> One might paraphrase it, perhaps, as:
>
> If it walks and quacks, then it walks and quacks.
>
> with the implication that (a) that's all you need to know, and (b)
> these capabilities unite this object with other objects with the same
> capabilities.

That's exactly what I thought was wrong with the common duck typing
saying. If it walks and quacks it is not a duck, it is something that
walks and quacks. Thanks for stating this. :)

georgesawyer

1/28/2005 11:55:00 AM

Florian Gross <flgr@ccan.de> Jan 26, 2005 at 01:54 PM wrote:

>David A. Black wrote:
>> One might paraphrase it, perhaps, as:
>> If it walks and quacks, then it walks and quacks.
>> with the implication that (a) that's all you need to know, and (b)
>> these capabilities unite this object with other objects with the same
>> capabilities.

>That's exactly what I thought was wrong with the common duck typing
>saying. If it walks and quacks it is not a duck, it is something that
>walks and quacks. Thanks for stating this. :)

The good thing is, Duck Typing is a great phrase to pull people in from
typed languages.

On the other hand, there are no types (in Ruby). In solving problems by
writing code, our supple, programmer creativity can explore all the
potential to dynamically add and subtract (perhaps even multiply) objects'
capabilities.

Petite Abeille

1/28/2005 12:13:00 PM

On Jan 28, 2005, at 12:56, georgesawyer wrote:

> The good thing is, Duck Typing is a great phrase to pull people in from
> typed languages.

I don't know. Sounds more like something to do with animal abuse to me
8^)

In any case... regarding "method injection"... yes... it sounds nifty
at first... like @implementation(Category), + poseAsClass:,
-respondsToSelector:, randomly moving IMP structures around or using id
for everything under the sun... but pretty soon... the "novelty" factor
wears out and you start worrying more about repeatedly shooting
yourself in the foot in unexpected ways than showing of your runtime
wizard'ize...

Cheers

--
PA, Onnay Equitursay
http://alt.text...

comp.lang.ruby

Re: Injecting methods from one class into another.