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!
On 21.09.2006 15:50, Ola B. 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.
I didn’t feel hurt in any way but accept your apology anyway (just in
case…)
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 Thu, Sep 21, 2006 at 03:39:12AM +0900, Joel VanderWerf wrote:
} Austin Z. wrote:
} >On 9/20/06, Ola B. [email protected] wrote:
} >>The problem with “just use it”, is that you will have no control
over
} >>error handling in this case.
} >
} >This is demonstrably untrue. Duck typing is not about validation.
It’s
} >about trusting your callers to do the right thing – and then doing
} >the right thing when they don’t.
}
} To extend Austin’s point a little: 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.
} vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
–Greg
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!
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.
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!
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.
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.
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.
On Fri, Sep 22, 2006 at 12:31:43AM +0900, Austin Z. wrote:
} On 9/21/06, Gregory S. [email protected] 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.
check doesn’t help you with arity checking, which matters as much as
harp:~ > cat a.rb
key = m.to_s
if super
os.x = ‘y’
puts “‘to_s’ artiy : #{ how.arity }”
‘to_s’ artiy : 0
cheers.
-a
in order to be effective truth must penetrate like an arrow - and that is
likely to hurt. – wei wu wei
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.
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.
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.
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 T., 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.
On Thu, Sep 21, 2006 at 03:39:12AM +0900, Joel VanderWerf wrote:
} To extend Austin’s point a little: 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.
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”,
Off Topic
Unnatural
Disturbing
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.
Do we need separate terms
to describe the different meanings Eric enumerated (and potentially
others)? Well, no, but it’d be helpful. I’ll start.
Oh, and lastly:
Can we expect everybody in the world to conform to a standard set of
vocabulary, should we come to agree on one? HELL NO!
Hmm that sounds strange to me:
Do you think we missunderstand each other on purpose?
Even if we were all native English speakers the limitations of the
written
language will kick in.
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.
Hopefully I got my point accross - which is funny because the point I
want
to get accross (is this English BTW?) is that is almost impossible to
get
the point accross.
Cheers
Robert
That is all.
Devin
–
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.
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
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.
Watch for my civil rights though
–
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.
