Proposal for a named parameter prefix

def foo(*array)
array.each do |a|
# …
end
end

Aha there’s an asterisk so we know it’s an array.

def foo2(&block)
@callback = block

end

Aha there’s an ampersand so we know it’s a block.

def foo3(what_is_this)

(many lines of code)

what_is_this.each |key,value|
# …
end
end

Hm what is what_is_this? Aha I see it’s the
ol’ named-parameter thing.

But wait there’s more! I can’t do

foo4(some, variable, number, of, elements,
:then => some, :named => parameters)

because such a definition

foo4(*array, params)

end

would be illegal since params would be splatted into the array.

I propose:

def foo4(*array,%params,&block)
array.each do |a|
# …
end
params.each do |key, value|
# …
end
@callback = block
end

from above,

def foo3(%what_is_this)

end

Aha there’s a percent sign so we know it’s a hash.

It’ll be backward compatible too. You’ll just get the current
behavior when there’s no percent sign. Also, the hash in

foo4( { :a => 4, :b => 5, :c => 6 } )

will be treated as a normal array argument.

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)

···


Jeff Mitchell

Hi,

I propose:

def foo4(*array,%params,&block)
array.each do |a|
# …
end
params.each do |key, value|
# …
end
@callback = block
end

from above,

def foo3(%what_is_this)

end

Aha there’s a percent sign so we know it’s a hash.

Why does a percent sign mean a hash?

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.

···

At Sun, 7 Sep 2003 04:13:18 +0900, Jeff Mitchell wrote:


Nobu Nakada

nobu.nokada@softhome.net wrote in message news:200309071005.h87A5o4D004546@sharui.nakada.kanuma.tochigi.jp

Hi,

I propose:

def foo4(*array,%params,&block)
array.each do |a|
# …
end
params.each do |key, value|
# …
end
@callback = block
end

from above,

def foo3(%what_is_this)

end

Aha there’s a percent sign so we know it’s a hash.

Why does a percent sign mean a hash?

Because it was the arbitrary character I chose in the proposal above.

Also, “coincidentally”, it happens to be perl’s sigil for hash (just like
“&” happens to be perl’s sigil for code block).

It doesn’t have to be a hash per se, just “the thing that holds named
parameters”.

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.

Hm? My first reaction is that it would be confusing since ** suggests
“splat twice” (whatever that means).

···

At Sun, 7 Sep 2003 04:13:18 +0900, > Jeff Mitchell wrote:

Jeff

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.

thanks

···


Jeff

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.

Sean O'Dell

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.

Hal

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

Hi,

Can you give a link to this discussion? I haven’t been able to find
it on google, rubygarden, etc.

Since Excite translation service was very funny, although I
tried, excuse bad translation.

[ruby-dev:8372] Re: keyword ( or hash ) argument

answering the question how to write a method definition has

keyword arguments.

It is same as Python. That is, optional arguments become
keyword arguments. And, you can get a Hash like Symbol =>
value with **.

Suppose

def foo(a=4, b=5, c=6, **keys)
end

and by invoking as foo(a: 1, d: 7, k: 44), you’ll get

a=1, b=5, c=6, keys = {:d=>7, :k => 44}

Unless there is **, undefined keywords occur error.

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

What about this?

module Kernel
def calling(meth, *args)
meth = method(meth)
Proc.new {meth.call(*args)}
end
end
p “this is a string”.calling(:slice, /is/).call

···

At Mon, 8 Sep 2003 08:36:57 +0900, “Sean O’Dell” <sean@cSePlsoAfMt.com[REMOVE_THE_SPAM]> wrote:


Nobu Nakada