Jim Weirich wrote:
> 
> On Nov 12, 2008, at 2:40 PM, Brian Candler wrote:
> 
>> I can't see, however, why you wouldn't just have an Array of Parameter
>> objects, rather than a separate Parameters container object.
> 
> 
> Not sure you could do #2 (convenient :to_s method) in that case.  
> Whether #2 is worth the extra class is another question (and worth asking)

I think I'm going to stick to my guns. I have full respect for the 
Parameter class and the behavior it brings to the table. However:

* I can't see the value in introducing a new class *just* for this one 
case. It's unlikely to see utility anywhere else, and this case doesn't 
seem enough to warrant adding it.
* The parameter elements are structurally so simple there's barely any 
behavior to add:

[param_type, param_name, default_value]

* Creating a type now damages the ability of this API to be stay 
backward-compatible without having to add new methods as new argument 
types come along. Do we define "keyword?" now? Do we provide support for 
multiple block arguments now?

Since we're building up a very simple structure for informational 
purposes only, the array of array seems like the least invasive and most 
flexible to me. And adding new types for small globs of structured data 
doesn't really seem like the Ruby way either:

* caller returns an array of strings representing the backtrace, not an 
array of StackTraceElement. Exception#backtrace does the same.
* Kernel#local_variables returns an array of strings, not an array of 
LocalVariableDescriptor elements.
* Kernel#select returns an array of arrays of IO, not an array of 
SelectedIOCollection entries.

Let's try to avoid over-designing this. The convenience of having a few 
nicer query or inspection methods is not enough to warrant saddling the 
parameter-list elements with whole classes, IMHO.

(Also, for the record, I think this kind of bikeshedding is *great*. 
These are important decisions, even if the details seem niggling or absurd.)

- Charlie