[ANN] Ducktator - A Duck Type Validator

[Austin Ziegler]

Actually, it is the developer's responsibility to override respond_to? when
overriding method_missing. To do one and not the other is just sloppy.

Maybe. I did point out that in my early days of programming Ruby, I
would implement one without the other. But simply doing a #respond_to?
check doesn't help you with arity checking, which matters as much as
the presence of the method itself.

-austin

 

[MonkeeSage]

But simply doing a #respond_to?
check doesn't help you with arity checking, which matters as much as
the presence of the method itself.

Very true. In the same way (as others have mentioned), method_missing
dispatching can cause some serious flaws in signature validation. And
method_missing with variable arity is even worse, heh!

Regards,
Jordan

 

[Jonas Pfenniger]

Very true. In the same way (as others have mentioned), method_missing
dispatching can cause some serious flaws in signature validation. And
method_missing with variable arity is even worse, heh!

And should #method, #instance_methods, ... also be overridden ? IMHO
it's better to avoid using method_missing in most cases, it makes code
more difficult to debug.

 

[ara.t.howard]

Maybe. I did point out that in my early days of programming Ruby, I
would implement one without the other. But simply doing a #respond_to?
check doesn't help you with arity checking, which matters as much as
the presence of the method itself.

-austin

that's pretty interesting austin - i haven't considered that before. i'm
already in the habit of checking arity on blocks and calling them with the
'correct' number of paramters - i wonder if a simple design pattern might help
with that situation, for example:

harp:~ > cat a.rb
#
# an open-struct class, with a demo impl of method_missing/respond_to pair
#
class OpenStruct
def initialize h = {}
(@h = {}).update h
end

def method_missing m, *a, &b
key = m.to_s
w = key.sub! %r/=$/, ''
if w
val = a.shift || b.call
@h[key] = val
else
@h[key]
end
end

def respond_to? m
if super
method m
else
key = m.to_s
w = key.sub! %r/=$/, ''
w ? lambda{|k,v|} : lambda{|k|}
end
end
end

os = OpenStruct.new 'key' => 'val', 'a' => 'b'
os.x = 'y'

if how = os.respond_to?('x')
puts "'x' artiy : #{ how.arity }"
end

if how = os.respond_to?('x=')
puts "'x=' artiy : #{ how.arity }"
end

if how = os.respond_to?('to_s')
puts "'to_s' artiy : #{ how.arity }"
end

if how = os.respond_to?('send')
puts "'send' artiy : #{ how.arity }"
end


harp:~ > ruby a.rb
'x' artiy : 1
'x=' artiy : 2
'to_s' artiy : 0
'send' artiy : -1


so, rather than returning a simple bool from 'respond_to?' we return an object
describing __how__ it responds - either a method object or a lambda, either of
which can be used to determin arity.

just a thought...

cheers.

-a

 

[Gregory Seidman]

On Fri, Sep 22, 2006 at 12:31:43AM +0900, Austin Ziegler wrote:
} >Actually, it is the developer's responsibility to override respond_to? when
} >overriding method_missing. To do one and not the other is just sloppy.
}
} Maybe. I did point out that in my early days of programming Ruby, I
} would implement one without the other. But simply doing a #respond_to?
} check doesn't help you with arity checking, which matters as much as
} the presence of the method itself.

The best duck typing language I know of is the C++ templating language.
When I'm writing the code all I have to think about is whether the
arguments I'm passing can do the things the templated methods are asking
them to do. The compiler verifies everything about arguments and return
types. Even though I have the flexibility and simplicity of a duck-typed
language I have a compiler to perform static analysis on the code and
perform contractual enforcement.

Ruby's dynamism gives me even more flexibility, but I lose that contractual
enforcement by static analysis. It's true that respond_to? is insufficient
because it doesn't give me arity, but it's better than nothing. I maintain
that overriding method_missing without also overriding respond_to? is
sloppy coding.

} -austin
--Greg

 

[ara.t.howard]

Ruby's dynamism gives me even more flexibility, but I lose that contractual
enforcement by static analysis. It's true that respond_to? is insufficient
because it doesn't give me arity,

but it certainly can - it's up to you whether is does or does not.

food for thought...

-a

 

[ara.t.howard]

No reason to go change the API...

it doesn't really - it's totaly backward compatible - it just happens to
return a method/proc object instead of true, but that wouldn't break anything.

If you want to get the arity of a method, you simply use #method to get the
method object and use arity on that. If you overrode #method along with
#method_missing, you could still implement this same behaviour. You might
make #method return a Proc instead of a Method for those cases, but it
shouldn't make much difference. So, these should really be overridden
together:

method_missing
respond_to?
method

You could put most of your logic in #method and have #method_missing and
#respond_to? use it.

interesting idea. of course my approach is just that - an idea. i actually
thought about that but decided against it because, although Method and Proc
objects both support arity, only method objects can be called with blocks so,
returning a Proc from self.method() would change, and possible break, the api.
of course - that's going to change in a newer ruby, and it's a really nice
idea.

cheers.

-a

 

[Hal Fulton]

Inspired by Jordan's sappiness, I would like to offer a public apology
for those who felt themselves slighted in anyway by what I have said in
this discussion, or in my blog post.

The blog entry was not an attack at the people who disagreed with me,
and if someone interpreted it in that way, I am sorry.

The point I was aiming at, is that this discussion about duck typing
seem to exhibit various interpretations of the concept, and everyone was
ready to defend their own versions of it, but there isn't an easy way to
say who was wrong or who right, since the concept is a philosophy more
than a practice or a technique.

I am truly sorry I even used the word duck typing for my project, no
matter if it has anything to do with duck typing or not.

The Ruby community is wonderful, and I didn't write with the intent of
trolling or driving a wedge in it.

Don't be *too* sorry... after all you have a right to your opinion.

I don't/didn't agree with your usage, but Matz thought there was some
validity in it. So how can I argue?

Three people I *rarely* dare disagree with are Matz, Dave Thomas, and
Guy Decoux. Usually I'll only disagree with one of them if it's a
clear-cut matter of opinion. In matters of pure fact, I consider all
of them to be smarter than I am, though they would not necessarily
claim it.

Anyway, please stick around. The ability to apologize is an important
skill in itself.


Hal

 

[Hal Fulton]

In ruby, it really has to be this
} way. What if an object responds to a message by way of method_missing?
} There's no easy way to validate that.

Actually, it is the developer's responsibility to override respond_to? when
overriding method_missing. To do one and not the other is just sloppy.

An interesting point, and tentatively it seems reasonable (though there
are probably exceptions).

Along those lines, you might also want to add the method to the
instance_methods list so that reflection works as expected.

One interesting variation on the use of method_missing that I've used
once or twice is: When method_missing is called, *create* the method
and make it do the "right thing." Then respond_to? and reflection
will henceforth work as expected.


Hal

 

[Kevin Jackson]

I will tell you something and I am deadly serious:

All that stuff "I am sorry", "appologies accepted", somebody even wrote "I
am glad you got together", Austin even said that he was "harsh",
1. Off Topic
2. Unnatural
3. Disturbing
4. Unnecessary

and please, please flame me, insult me, but *do not* appologize, that is
outrageous, where do you think you are? do you want to impress us with
"civilized manners", c'on!

Hear, hear! After all how could the great "Ducktator" flame fest
continue with people apologizing and stuff - it's the end of the
Internet I tell ya!

Kev

 

[dblack]

Hi --

The point I was aiming at, is that this discussion about duck typing seem to
exhibit various interpretations of the concept, and everyone was ready to
defend their own versions of it, but there isn't an easy way to say who was
wrong or who right, since the concept is a philosophy more than a practice or
a technique.

It seems to me that duck typing exhibits a kind of self-similar
behavior with respect to both what it is and what it describes: in
other words, people seem to take the view that, "If it walks like duck
typing and quacks like duck typing, then it is duck typing"

So we've ended up with a proliferation of concepts, practices,
modules, libraries, etc. with the word "duck" floating around them.
Some of these things are, in themselves, quite interesting and
resourceful, but they'd be better off without "duck".

I guess I'm old-fashioned; I think Dave's discussion and explanation
of duck typing is still authoritative, clear, and unimproved upon by
subsequent borrowings of the term. But it's true that the term has
become very vexed, unfortunately, so that it's hard to use it
"innocently" to refer to what Dave was talking about.

So maybe we need "Thomasine typing" or something like that


David

--
David A. Black | (e-mail address removed)
Author of "Ruby for Rails" [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

 

[Lyle Johnson]

I will tell you something and I am deadly serious:

All that stuff "I am sorry", "appologies accepted", somebody even wrote "I
am glad you got together", Austin even said that he was "harsh",
1. Off Topic
2. Unnatural
3. Disturbing
4. Unnecessary

and please, please flame me, insult me, but *do not* appologize, that is
outrageous, where do you think you are? do you want to impress us with
"civilized manners", c'on!

Just for that, I think I'm going to have to blog about you.

 

[Rick DeNatale]

I've put my 10 cents about this thread in my blog.

http://talklikeaduck.denhaven2.com/articles/2006/09/21/schrödingers-duck

 

[Rick DeNatale]

No I have to say that I find this a very interesting and didactic thread,
look e.g. at your statement
"Boy, we really love to argue about semantics, don't we?"
it struck me, for meself it is one of the main purposes of the ML, for
yeself it seems unnecessary, I guess we do not interpret the sentence in the
same way, and I assume that we do not do this on purpose.

I've always been bemused when someone says, "It's just a question of
semantics" to cut off a discussion. Doesn't semantics mean "meaning"
and if so, it seems to me that that's more interesting to discuss
than, say, syntax.

Hopefully I got my point accross - which is funny because the point I want
to get accross (is this English BTW?)

Yes, except for the spelling of across.

is that is almost impossible to get
the point accross.

Amen!

 

[Rick DeNatale]

I will tell you something and I am deadly serious:

All that stuff "I am sorry", "appologies accepted", somebody even wrote "I
am glad you got together", Austin even said that he was "harsh",
1. Off Topic
2. Unnatural
3. Disturbing
4. Unnecessary

and please, please flame me, insult me, but *do not* appologize, that is
outrageous, where do you think you are? do you want to impress us with
"civilized manners", c'on!

"Why can't we just get along?"

Wait a minute.....

http://talklikeaduck.denhaven2.com/articles/2006/09/13/humility-and-advocacy