Hal Fulton wrote:
> Sean O'Dell wrote:
> 
>> Jeff Mitchell wrote:
>>
>>> nobu.nokada / softhome.net wrote in message 
>>> news:<200309071005.h87A5o4D004546 / sharui.nakada.kanuma.tochigi.jp>...
>>>
>>>>> To summerize, "%" gets us two things
>>>>>
>>>>>  (1) a nice signal to let everyone know a named parameter hash is
>>>>>      there
>>>>>
>>>>>  (2) the ability to mix variable-length arguments with named
>>>>>      parameters (in a nice way)
>>>>
>>>>
>>>>
>>>> IIRC, matz has thought ** for it.
>>>
>>>
>>>
>>>
>>> Can you give a link to this discussion?  I haven't been able to find
>>> it on google, rubygarden, etc.
>>
>>
>>
>> If it's possible, I would prefer that Ruby DOESN'T get another 
>> #$%^-style idiosyncracy added.  Why can't named parameters just go 
>> something like this:
>>
>>     def method(param1)
>>     end
>>
>>     method(:param1 = "value")
>>
>> ....and just accept parameters as normal, except when the first named 
>> parameter is encountered, assume the remaining parameters sent from a 
>> call are out-of-order and will also be named parameters.  In other 
>> words, handle it transparently to the method, backwards-compatible 
>> with existing code and without a new non-letter-character being used 
>> to denote a syntax idiom.
> 
> 
> I agree with Sean. The exception would be that the last
> parameter can be a block as usual.

Another idea occurred to me:

Could a "calling context" be prepared as an object, which allows you to 
set parameters as methods and then "make the call" in one atomic action? 
  By this I mean, the code could do something like:

something = "this is a string"
call = Call.new(something, :slice)
call.params["pattern"] = /is/
call.call()
print call.result

I think right now I could do that as a C extension object, except I am 
unsure of how to determine the order I should pass in the parameters to 
String::slice.  If the parameter names that slice expects are somehow 
determinable, this would be cake.

If done as an extension to the Proc object, the environment when the 
Call object was created could be saved as well, just like a Proc object.

Or perhaps even just extend the Method object to do this.

Hmm ...

	Sean O'Dell