From: "trans.  (T. Onoma)" <transami@...>
Date: 2005-01-17T00:32:08+09:00
Subject: Passive Arguments

Since Ruby doesn't support signature-based method definitions, what good does 
it do to throw errors on the wrong number of arguments? Seems to me, this 
just makes the programmers job more difficult. What if Ruby nil'd unspecified 
parameters and ignored extra parameters. Eg.

  def ameth(a,b)
    a.to_i + b.to_i
  end

  ameth         #=> 0
  ameth(1)      #=> 1
  ameth(1,2,3)  #=> 3

Perhaps there is a problem with doing this that I don't see, but it's more in 
line with Ruby's dynamic behavior. Testing is were such errors should be 
caught, if indeed these are errors. This is the standard explanation one gets 
about duck-typing after all. Why wouldn't it apply here as well? And it's not 
like it can't be done either. As it stands, to achieve the same effect I must 
conceive of it a bit differently as:

  def ameth( *args )
    args[0].to_i + args[1].to_i
  end

So it's not like it should not be done. We do it all the time.

Okay so this leads me to my next thought about passive arguments. As you all 
probably know I've been working on AOP for awhile and one thing to come up is 
how to deal with the method signatures of advice. Since one advice method can 
wrap multiple regular methods there's the problem of dealing with variant 
signatures. For example look at this psuedo-code:

  def x(a)
    ...

  def y(a,b)
    ...

  def w
    puts "Advising"
    super  # calls the advised method
  end
 
  wrap :w => [ :x, :y ] 

So #w wraps both #x and and #y. Obviously there's going to be a problem with 
the arguments. The fix is of course to do 'def w(*args, &blk)' instead. And 
indeed as far as wraps go one will ALWAYS end up having to do that. It would 
be much nicer if one could do 'def w(a,b)' and it would still work --hence 
the beginning of this post. 

Also, since there will be occasions when the args won't matter it might be 
nice too, if not specifying any parameters meant that they were simply passed 
on through to super. In other words:

  def w
    puts "Advising"
    super  # calls the advised method
  end

were exactly the same as doing:

  def w(*args, &blk)
    puts "Advising"
    super(*args, &blk)  # calls the advised method
  end

and to actually change the interface one would have to do so explicitly, just 
as one has to be with #super currently:

  def w()  # changes the interface
    puts "Advising"
    super  # calls the advised method
  end

What do you think?
T.