named parameters idiom

[Fernando Cacciola]

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

 

[David A. Black]

Hi --

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:

enrollapplicant => 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

--
Upcoming training by David A. Black/Ruby Power and Light, LLC:
* Advancing With Rails, Edison, NJ, November 6-9
* Advancing With Rails, Berlin, Germany, November 19-22
* Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!

 

[Fernando Cacciola]

Hi --



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

enrollapplicant => 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?

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")

Now that's cool.

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

 

[Rick DeNatale]

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).

 

[ara.t.howard]

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/

 

[Fernando Cacciola]

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

Good point

Best

Fernando