[ANN] Ducktator - A Duck Type Validator

ruby-talk
61

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

···

On Fri, Sep 22, 2006 at 12:31:43AM +0900, Austin Ziegler wrote:
} On 9/21/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> wrote:

62

Ah thank-you, that's great. But it would not work unless every
execution path within the method receiving the object was executed:

Well, yes. I didn't say it's perfect. :slight_smile:

..so is there some magic that could overcome that limitation?

You could make Probe significantly more complex so that it records invoked methods and alters the return value between true and false or something else etc. and goes on probing until no new execution sequences are found. I guess this can soon get messy...

Regards

    robert

···

Leslie Viljoen <leslieviljoen@gmail.com> wrote:

63

What a shameful blog post, Ola. Since you're not interested in
dialogue, I'll join your monologue with a blog post, myself. You're
welcome not to read it or to read it, but you should be ashamed of
your blog post here.

http://www.halostatue.ca/2006/09/20/duck-typing-getting-it-name-calling-and-ola-bini/

-austin

···

On 9/20/06, Ola Bini <ola.bini@ki.se> wrote:

I don't want to continue this discussion in this venue, since the
discussion isn't really about what I meant with the project and such.
Duck typing also seems to be a very loaded (might I say religious) word
for people in the Ruby-community.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

64

Hal Fulton wrote:

One thing I'm wondering is: Is there any evidence that this term
originated *other than* with Dave Thomas?

Certainly it's known outside the Ruby community now, but didn't the
term originate *within* the community?

Not that it matters really. AFAIK Dave himself doesn't claim to have
coined the term. And I take it for granted that the concept is older
than the term.

From everything I can gather Mr. Thomas at least popularized the term

if not coined it. I just meant that I didn't know if he used the term
differently from the way it has now become generalized and applied to
other languages or theories of language design. I just found this,
however, which is rather interesting [1].

I'm not adamant about it. And I do perform this kind of checking
sometimes (gasp!).

What!? You actually do that? Are you some kind of communist or
something? Stop oppressing your objects and just leave them be free to
be who they want to be!! Heh. :stuck_out_tongue_winking_eye:

[1] http://wiki.rubygarden.org/Ruby/page/show/DuckTyping

···

========

Devin Mullins wrote:

MonkeeSage wrote:
> I trust everything that Wikipedia says.
(Well, I paraphrased that a bit...)

LOL! Well I did quote WP alot, didn't I. It was just easier that trying
to 'splain all that stuff myself (and I have a tendency to be
ambiguous, if you haven't noticed already, heh).

(I was kidding, Jordan. Just messing wit j00. I lack knowledge of
category theory.)

No worries, I caught that you were just kidding. We's c00, mang. :wink:

* Scanning over chapter 23 of the PickAxe seems to confirm that that was
the intention -- pages 370-1 use the phrases "duck typing philosophy"
and "this style of laissez-faire programming," though, granted, the book
isn't consistent. Hey, the phrase is out there. It doesn't seem to have
a canonical definition. It's an ad hoc term. Treat it as such, I say.

Interesting. So, judging by the link I posted above in reply to Hal,
and this reference, it seems that sometimes Mr. Thomas uses the word in
different ways (or as a qualifier that nuances it differently).

Tim Bates touched on the topic in a mailing list post from 2004: "How
to duck type? - the psychology of static typing in Ruby" [2] He
considers the object signature validation approach (which he labels as
(3)) to be compatible with duck typing, but not the "Zen" of it (which
he labels as (4)), which is just to use the object.

David Black also has some interesting comments in this RCR [3].

[2] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511
[3] RCR 318: easy way(s) to make a duck

I personally don't really care how one uses the term, but I just think
that one valid use is the way myself and Ola were using it. Of course,
I'm not biased toward the definition I use -- this is a purely
objective observation! :wink:

Cheers to you and Hal,
Jordan

65

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.

···

--
  Ola Bini (http://ola-bini.blogspot.com)
  JvYAML, RbYAML, JRuby and Jatha contributor
  System Developer, Karolinska Institutet (http://www.ki.se)
  OLogix Consulting (http://www.ologix.com)

  "Yields falsehood when quined" yields falsehood when quined.

66

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.

···

On 21/09/06, MonkeeSage <MonkeeSage@gmail.com> wrote:

Austin Ziegler wrote:
> 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!

--
Cheers,
  zimbatm

http://zimbatm.oree.ch

67

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

food for thought...

-a

···

On Fri, 22 Sep 2006, Gregory Seidman wrote:

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,

--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

68

No reason to go change the API... 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.

···

On 9/21/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

On Fri, 22 Sep 2006, Austin Ziegler wrote:

> On 9/21/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> 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.
>
> -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
--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

69

Yes, it starts out as a nice idea. And while it's doing all that
probing, who knows what side-effects it might be producing in that
alien code?!

Let me see, why not try:

format_harddrive_if_input_above_5(probe)

Whoops!

Anyway, there are still places where it helps, I'm not complaining :wink:

Les

···

On 9/20/06, Robert Klemme <shortcutter@googlemail.com> wrote:

Leslie Viljoen <leslieviljoen@gmail.com> wrote:
> Ah thank-you, that's great. But it would not work unless every
> execution path within the method receiving the object was executed:

Well, yes. I didn't say it's perfect. :slight_smile:

> ..so is there some magic that could overcome that limitation?

You could make Probe significantly more complex so that it records invoked
methods and alters the return value between true and false or something else
etc. and goes on probing until no new execution sequences are found. I
guess this can soon get messy...

70

Hmm, and just a few hours back I was saying in my journal how friendly
the Ruby community is (http://lesliev.livejournal.com). But then I
didn't think everyone was going to let Ola post-and-run like that, no
siree!

···

On 9/20/06, Austin Ziegler <halostatue@gmail.com> wrote:

On 9/20/06, Ola Bini <ola.bini@ki.se> wrote:
> I don't want to continue this discussion in this venue, since the
> discussion isn't really about what I meant with the project and such.
> Duck typing also seems to be a very loaded (might I say religious) word
> for people in the Ruby-community.

What a shameful blog post, Ola. Since you're not interested in
dialogue, I'll join your monologue with a blog post, myself. You're
welcome not to read it or to read it, but you should be ashamed of
your blog post here.

You are in a maze of twisty little passages, all alike. // halo • statue

71

Apology accepted. I have been a little harsh in my response to your
post, so I apologize for the harshness involved. I'd actually like to
chat with you off-list, if you're amenable to that.

-austin

···

On 9/21/06, Ola Bini <ola.bini@ki.se> wrote:

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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

72

First of all: great that you all found a way back together - this does not happen often in forum / newsgroup discussions - which exactly supports what Jordan said about our community!

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.

I didn't feel hurt in any way but accept your apology anyway (just in case...) :slight_smile:

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 had a different perception of the discussion: actually I think there were at least several individuals who agreed on an interpretation. Maybe you could say that there were distinct groups that shared a common understanding each.

And, yes, of course /I/ was right. It's that easy to say... ;-)))

Kind regards

  robert

PS: Ducktator is a great name nevertheless. I like puns.

···

On 21.09.2006 15:50, Ola Bini wrote:

73

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

···

On Fri, 22 Sep 2006, Eric Mahurin wrote:
--
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. -- wei wu wei

74

Ola Bini wrote:

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? :wink:

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

75

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" :slight_smile:

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

David

···

On Thu, 21 Sep 2006, Ola Bini wrote:

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

76

Austin Ziegler wrote:

···

On 9/21/06, Ola Bini <ola.bini@ki.se> wrote:

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.

Apology accepted. I have been a little harsh in my response to your
post, so I apologize for the harshness involved. I'd actually like to
chat with you off-list, if you're amenable to that.

-austin

Good, *shake hands*

Sure thing, as long as it isn't about duck typing. =)

--
  Ola Bini (http://ola-bini.blogspot.com)
  JvYAML, RbYAML, JRuby and Jatha contributor
  System Developer, Karolinska Institutet (http://www.ki.se)
  OLogix Consulting (http://www.ologix.com)

  "Yields falsehood when quined" yields falsehood when quined.

77

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!

Cheers
Robert

···

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

78

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

79

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

···

On 9/22/06, Robert Dober <robert.dober@gmail.com> wrote:

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!

80

"Why can't we just get along?"

Wait a minute.....

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

···

On 9/22/06, Robert Dober <robert.dober@gmail.com> wrote:

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!

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/