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
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
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:
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
On Tue, 6 Nov 2007, Fernando Cacciola wrote:
--
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!
def another_idiom options = { :can => 'be enumerated here for clarity', :if => 'you want the signature to be more declarative' }
end
cheers.
On Nov 6, 2007, at 4:46 AM, Fernando Cacciola 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.
--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama
David A. Black wrote:
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: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?
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")
Now that's cool.
How would the enroll() function definition look in 1.9?
On Tue, 6 Nov 2007, Fernando Cacciola wrote:
--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com
And (c) it allows for an arbitrary number of truly optional arguments
which are order independent. Which is really just amplifying on (b).
On 11/6/07, David A. Black <dblack@rubypal.com> 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.
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
ara.t.howard wrote:
On Nov 6, 2007, at 4:46 AM, Fernando Cacciola 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
Good point
Best
Fernando