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

On Tue, 6 Nov 2007, Fernando Cacciola 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

--
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!

David A. Black wrote:
> Hi --
>
> On Tue, 6 Nov 2007, Fernando Cacciola 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")
>
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?


--
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com

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.

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/

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

cheers.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama

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