From: Robert Dober <robert.dober@...>
Date: 2007-06-28T04:50:33+09:00
Subject: Re: Named/positional method args

> > > Smalltalk? 35 years ago, I think Rick confirmed the now famous Alain
> > > Kay quotation about Smalltalk beating Java, but being called Ruby.
>
> Actually that was Kent Beck not Alan.

That one hurts all my apologies. c.f. my new signature BLUSH

>
> >
> > :) I'm not really arguing against duck-typing. I just don't think it's
> > necessarily in opposition to specifying optional parameter types. If
> > the the whole duck-typing idea was more deeply pursued we might even
> > find it quite intuitve to do so, using Mixins:
> >
> >   def foo(a < Enumerable)
>
> But see the warning above.
I feel I want to think about this notation - or rather the idea behind
it - a little bit more.
My rationale for such a device -- and at first sight it seems a good
device to me -- would be something like this:

ok we will work on an object a and we know of course that we will use
a certain interface  with a. Please note that I will remain 100% in a
Duck Type/Protocol context.
So please Tom if I am wrong with your basic idea just hit me, but I
will take the risk this is too interesting :).
Let us assume that we will call #abra and #kadabra -- I am staying
away from real use cases.
In an ideal world I just do not care because of course nobody will
ever pass an object not responding (1) to these messages.
The ideal world has yet to be invented though :(. Therefore sometimes
we will have some NoMethodError exceptions and that is how it is.
Sometimes -- also not true in an ideal world -- someone will try to
figure out what foo does with a, and she will read the code and
eventually find out - or not;).

That was the scenario <c>def foo a</c>, now we will create a new scenario
<c>
module AbraKadabra
   def abra...
   def kadabra
end

def foo a < AbraKadabra
</c>

now we will fail earlier and with a meaningful error message...

I know we have had this discussion and while I am writing this I feel
that there is something wrong with my picture, the creation of a
module for the purpose feels so wrong, let us have another try
<uc> ## utopic code ;)
protocol AbraKadabra
   methods :abra, :kadabra ## no way to say something about arity!
end
def foo a < AbraKadabra
</uc>

I know we have doc's and tests but we have to write them ourselves,
maybe the Ruby Interpreter should just ignore protocols and they could
be used for rdoc and automatic test generation only!!!

>
> > > > Slightly aside, but I would also point out that a language which is
> > > > serious about duck-typing would do well to support complete method
> > > > probing. We should be able to pass "decoy" parameters to any method,
> > > > acting in DryRun fashion, and record all possible calls made on them.
> > > > I suspect such a tool would be invaluable in ascertaining the common,
> > > > essential methods we apply to different representations.
> > >
> > > Hmm me bad, I do not understand this, could you mabye give an example please?
> >
> > A method probe is something like this:
> >
> >   class Decoy
> >     private *instance_methods
> >     attr_accessor :_record
> >     def initialize()
> >       @_record = []
> >     end
> >     def method_missing(sym, args, blk)
> >       @_record << [sym, args, blk]
> >     end
> >   end
> >
> > Now I can take any method I want which takes a parameter and drop the
> > decoy in:
> >
> >   def foo(x)
> >     x.to_s
> >   end
> >
> >   d = Decoy.new
> >   foo(d)
> >   d._record  #=> [[:to_s, nil, nil]]
> >
> > In this way we can see what kind of "duck" a parameter requires.
> >
> > This isn't perfect however because of possible side-effects and
> > conditionals, which can skew the results. We would require a dry-run
> > mode and some dynamic means of dealing with condition statements (eg.
> > a decoy would split down both paths of any condition). It's not an
> > easy problem, but I don't think it is impossible either --at least not
> > impractically so.
I start grasping the concept, thx a lot.
<snip>

Robert
-- 
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Back