Mikael Høilund wrote:
> It will also make handling of the returned object much prettier. I'd 
> much rather see
> 
> method(:foo).parameters.names.include? :some_param
> 
> than
> 
> method(:foo).parameters.any? { |param| param.include? :some_param if 
> param.kind_of? Array }
> 
> or however it would be represented. Similarly, what expresses what you 
> want the most; `parameters.takes_block?` or `!parameters.last.nil?`?

Strongest argument I've seen for a real class. I'm more in favor of that 
now.

> I'm also in favor of supplying the default value. In far the most cases 
> the default value is nil (in my experience), but not always. This means 
> I'll have to look up the method (don't get me started on if the method 
> is dynamically generated) just to pass an optional argument that follows 
> another optional argument I don't want to change.

Oh yeah, nil...I knew I missed something in the JRuby impl.

I suppose a short list of defaults that should work would be:

* literal numerics
* symbols
* strings
* nil
* booleans
* empty array or hash

It could also potentially support more, though these start to get a 
little rare and subjective:

* regexp
* hash or array with all literals (nested?)
* constants

Again...I'm in favor of just simple literals, excluding empty array and 
hash.

> Default values, however, I can see becoming a bit of a hassle. Unless 
> it's to be represented as a string of Ruby code, cases like `def foo 
> bar, baz = "default-#{bar}"` will be quite difficult to express, let 
> alone in a way that's easy and nice to handle.

A string of Ruby code is next to impossible to do efficiently and 
portably, so I think it can be the above set of literals at best.

- Charlie