[ruby-core:19899] Re: Proposal: Method#get_args

On Nov 12, 2008, at 4:12 PM, Charles Oliver Nutter wrote:
> 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:
[...]
> * The parameter elements are structurally so simple there's barely  
> any behavior to add:
>
> [param_type, param_name, default_value]

<nod> And I'm not too happy with the required?/optional? suggested  
behavior.  But I can't quite put my finger on why.

> * 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?

Add new query methods or add new type symbols ... both seem equally  
non-backward compatible.

> [...] 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.

And while I strongly disagree with the design decisions on caller/ 
backtrace (there is a lot of useful information in the strings that  
can only be retrieved via brittle parsing), the args arrays proposed  
here don't require parsing so are more in line with the other two  
suggestions.

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

Agreed.

I see both sides, but I think I still lean slightly toward a  
lightweight Parameter class.  Returning things ordered positionally[1]  
in an array seems more like the FORTRAN way than the Ruby way.

-- 
-- Jim Weirich
-- [e-mail]

[1] I tend to prefer connascence of name over connascence of position.