params v.s. @params in rails?
Barry
difference and when should each one be used?
David A. Black
On Sun, 4 Sep 2005, Barry wrote:
> Both work in my controller class, so I am wondering what's the
> difference and when should each one be used?
To the extent that this is a Rails question, you might want to ask it
in a Rails forum (mailing list or IRC channel).
Meanwhile, the non-Rails-specific answer is that the bareword "params"
is a local variable, while "@params" is an instance variable. Local
variables are mainly a kind of "scratchpad" or temporary holding area
for data in the current local scope. Instance variables are unique
per object, rather than per scope, and give your objects a way to
maintain state across different methods and local scopes.
David
--
David A. Black
dbl...@wobblini.net
Dema
method to the @params instance variable, not a local variable. So, in
practice, they´re equivalent.
The recommendation for using the params method, instead of accessing
the @params instance variable directly, is that it´s more uniform to
use the accessor method, since you can also do that from the view.
David A. Black
while the remaining parts are likely unreadable without MIME-aware tools.
Barry
ActionController::Base of actionpack that explains what you are
describing,
attr_accessor :params
David Heinemeier Hansson
> the @params instance variable directly, is that it´s more uniform to
> use the accessor method, since you can also do that from the view.
Direct access to these instance variables is deprecated. The same goes
for cookies, session, request, response, and the other accessors. Use
the accessor instead of going directly, so it's request.get? instead
of @request.get?.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework
Marcel Molina Jr.
> > The recommendation for using the params method, instead of accessing
> > use the accessor method, since you can also do that from the view.
>
> Direct access to these instance variables is deprecated. The same goes
> for cookies, session, request, response, and the other accessors. Use
> the accessor instead of going directly, so it's request.get? instead
> of @request.get?.
Another reason is that the accessor method conceals the actual implementation
of params from the client which allows for a more flexible and cleaner
design.
marcel
--
Marcel Molina Jr. <mar...@vernix.org>
Douglas Livingstone
> > The recommendation for using the params method, instead of accessing
> > the @params instance variable directly, is that it´s more uniform to
> > use the accessor method, since you can also do that from the view.
>
> Direct access to these instance variables is deprecated. The same goes
> for cookies, session, request, response, and the other accessors. Use
> the accessor instead of going directly, so it's request.get? instead
> of @request.get?.
>
Is there a one-stop reference to the best practices for this sort of thing?
Douglas
Ron Jeffries
<david.he...@gmail.com> wrote:
>> The recommendation for using the params method, instead of accessing
>> the @params instance variable directly, is that it愀 more uniform to
>> use the accessor method, since you can also do that from the view.
>
>Direct access to these instance variables is deprecated. The same goes
>for cookies, session, request, response, and the other accessors. Use
>the accessor instead of going directly, so it's request.get? instead
>of @request.get?.
David, Chet Hendrickson and I are just getting back to Ruby after too long away,
and we've just started working through the Rails book. Mostly happy so far,
though we're just a couple of days in.
One thing that confused me was the validate method in the first example. I'm
sure I'm missing something really obvious, but I'd rather be embarrassed than
confused. ;-> The validate is:
def validate
errors.add(:price, "should be positive") unless price.nil? || price >= 0
end
I don't see how "price" canrefer to the field in the record, unless price
isperhaps an accessor kind of method. But in the class definition, I don't see
any declaration of a price method.
If it's not too much trouble, since we seem to be close to the topic ... what's
up with that? How does that access to price work?
Thanks,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Devin Mullins
>David, Chet Hendrickson and I are just getting back to Ruby after too long away,
>and we've just started working through the Rails book. Mostly happy so far,
>though we're just a couple of days in.
>
>One thing that confused me was the validate method in the first example. I'm
>sure I'm missing something really obvious, but I'd rather be embarrassed than
>confused. ;-> The validate is:
>
> def validate
> errors.add(:price, "should be positive") unless price.nil? || price >= 0
> end
>
>I don't see how "price" canrefer to the field in the record, unless price
>isperhaps an accessor kind of method. But in the class definition, I don't see
>any declaration of a price method.
>
>If it's not too much trouble, since we seem to be close to the topic ... what's
>up with that? How does that access to price work?
>
>
Ron,
I'm nowhere near a Rails expert, and I'm definitely not David, but I do
own the book, and the example you're referring to (page 62) says that
this code goes in the model object. In the model object, yes, price is a
method invocation on self (a Product object) that returns the content of
the price column for that row. In Ruby, any undecorated symbolic
reference 'whatever' looks for a local variable first, and if not
defined? whatever, calls self.whatever.
If you're pulling up script/console and doing a Product.instance_methods
and not finding "price" listed, don't fret. It's most likely using
Product#method_missing (i.e. #doesNotUnderstand).
Hope that answers your question. Also, hope it's right. :)
Devin
Ara.T.Howard
> On Mon, 5 Sep 2005 01:26:44 +0900, David Heinemeier Hansson
> <david.he...@gmail.com> wrote:
>
>>> The recommendation for using the params method, instead of accessing
>>> the @params instance variable directly, is that it愀 more uniform to
>>> use the accessor method, since you can also do that from the view.
>>
>> Direct access to these instance variables is deprecated. The same goes
>> for cookies, session, request, response, and the other accessors. Use
>> the accessor instead of going directly, so it's request.get? instead
>> of @request.get?.
>
> David, Chet Hendrickson and I are just getting back to Ruby after too long away,
> and we've just started working through the Rails book. Mostly happy so far,
> though we're just a couple of days in.
>
> One thing that confused me was the validate method in the first example. I'm
> sure I'm missing something really obvious, but I'd rather be embarrassed than
> confused. ;-> The validate is:
>
> def validate
> errors.add(:price, "should be positive") unless price.nil? || price >= 0
> end
>
> I don't see how "price" canrefer to the field in the record, unless price
> isperhaps an accessor kind of method. But in the class definition, I don't see
> any declaration of a price method.
runtime and compile time aren't that different in ruby:
harp:~ > cat a.rb
class Row < ::Array
FIELDS = %w( product price )
def method_missing(m, *a, &b)
idx = FIELDS.index m.to_s
return self[idx] if idx
super
end
end
row = Row[ 'foobar', '17 bucks' ]
p row.price
harp:~ > ruby a.rb
"17 bucks"
this routes through method_missing each time, which is expensive, but you can
define the method at that point so future calls don't:
harp:~ > cat a.rb
class Row < ::Array
FIELDS = %w( product price )
def method_missing(m, *a, &b)
idx = FIELDS.index m.to_s
if idx
puts 'defining the method once...'
self::class.class_eval <<-definition
def #{ m }
self[ #{ idx } ]
end
definition
send m
else
super
end
end
end
row = Row[ 'foobar', '17 bucks' ]
2.times{ p row.price }
harp:~ > ruby a.rb
defining the method once...
"17 bucks"
"17 bucks"
it's precisely these sorts of possibilties which makes ruby such an attractive
means of writing code with dynamic responsibilies and requirements..
cheers.
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================
Neville Burnell
>> Sent: Thursday, 15 September 2005 1:22 PM
>> To: ruby-talk ML
>> Subject: Re: params v.s. @params in rails?
>>
>> def method_missing(m, *a, &b)
>> idx = FIELDS.index m.to_s
>> return self[idx] if idx
>> super
>> end
>>
Intuitively it sounds expensive, because [I imagine] ruby needs to
traverse then inheritance tree for the object, but in a simply case like
your example is it still expensive, ie, is method_missing much more
expensive than any other call ?
Neville
Ara.T.Howard
no. it is just a method. it's pretty easy to tell what happens from eval.c:
..
/* is it in the method cache? */
ent = cache + EXPR1(klass, mid);
if (ent->mid == mid && ent->klass == klass) {
if (!ent->method)
return method_missing(recv, mid, argc, argv, scope==2?CSTAT_VCALL:0);
klass = ent->origin;
id = ent->mid0;
noex = ent->noex;
body = ent->method;
}
..
it probably isn't an issue in this simple example but if you were, say,
scanning a ten thousand things to determine an index then you be a winner. it
definitely would require being able to do some sort of caching to make defining
the method worth bothering. i was just trying to show how you could have
something like 'price' work without it actually being 'defined' anywhere.
rails leverages ruby to the hilt with things like this.