Named parameters idiom

Ruby
1

Hi people,

I often see hashes used as a form of named parameters, with some
variations.
However, I couldn’t find the idiom properly explained anywhere.
I’m just missing it? Where is it?

Would anyone like to explain the idiom here? specially, when, why and
how it
is recommended.

It worries me that while it adds clarity at the point of call, it takes
it
away at the function defintion point, so I haven’t dare to use it yet.

TIA

2

Hi –

On Tue, 6 Nov 2007, Fernando C. wrote:

Hi people,

I often see hashes used as a form of named parameters, with some variations.
However, I couldn’t find the idiom properly explained anywhere.
I’m just missing it? Where is it?

Would anyone like to explain the idiom here? specially, when, why and how it
is recommended.

You pass a hash to the method, using pre-determined keys that serve as
pseudo-keywords. For example:

enroll(:applicant => person, :date => Time.now, :status => “admin”)

(Notice that I don’t have to wrap the hash in curly braces. The rule is
that if a hash is the last thing in the argument list, you can drop
the braces.)

The “why” part of it is that it gives the caller a way to (a) document
what the arguments are for a little bit, and (b) not worry about the
order of arguments, since hash keys can appear in any order.

It worries me that while it adds clarity at the point of call, it takes it
away at the function defintion point, so I haven’t dare to use it yet.

It’s a bit wordier than plain local variable names, but usually worth
the trade-off if you think it’s important to make things a little
easier for the caller.

Note that in 1.9, my example could be written as:

enroll(applicant: person, date: Time.now, status: “admin”)

David

3

David A. Black wrote:

Would anyone like to explain the idiom here? specially, when, why
and how it is recommended.

You pass a hash to the method, using pre-determined keys that serve as
pseudo-keywords. For example:

enroll(:applicant => person, :date => Time.now, :status => “admin”)

OK

then enroll would just look like this:

def enroll ( args = {} )
args[:applicant]

etc

end

right?

(Notice that I don’t have to wrap the hash in curly braces. The rule
is that if a hash is the last thing in the argument list, you can drop
the braces.)

Ha… I missed this.

The “why” part of it is that it gives the caller a way to (a) document
what the arguments are for a little bit, and (b) not worry about the
order of arguments, since hash keys can appear in any order.

Ya, it looks more clear to the caller.

I often see a mix of unnamed and named parameters in the same function.
Is
there an implicit convention to use named params for optional arguments
mainly?

enroll(applicant: person, date: Time.now, status: “admin”)

Now that’s cool.

How would the enroll() function definition look in 1.9?

4

On Nov 6, 2007, at 4:46 AM, Fernando C. wrote:

It worries me that while it adds clarity at the point of call, it
takes it away at the function defintion point, so I haven’t dare to
use it yet.

def another_idiom options = { :can => ‘be enumerated here for
clarity’, :if => ‘you want the signature to be more declarative’ }
end

cheers.

a @ http://codeforpeople.com/

5

ara.t.howard wrote:

Good point

Best

Fernando

6

On 11/6/07, David A. Black [email protected] wrote:

The “why” part of it is that it gives the caller a way to (a) document
what the arguments are for a little bit, and (b) not worry about the
order of arguments, since hash keys can appear in any order.

And (c) it allows for an arbitrary number of truly optional arguments
which are order independent. Which is really just amplifying on (b).

Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/