params v.s. @params in rails?

Discussion in 'Ruby' started by Barry, Sep 4, 2005.

  1. Barry

    Barry Guest

    Both work in my controller class, so I am wondering what's the
    difference and when should each one be used?
    Barry, Sep 4, 2005
    #1
    1. Advertising

  2. Hi --

    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
    David A. Black, Sep 4, 2005
    #2
    1. Advertising

  3. Barry

    Dema Guest

    Not really. In this particular case, params is simply an accessor
    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 wrote:
    > Hi --
    >
    > 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
    >
    Dema, Sep 4, 2005
    #3
  4. --8323328-357633517-1125848011=:1089
    Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-357633517-1125848011=:1089"

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    --8323328-357633517-1125848011=:1089
    Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
    Content-Transfer-Encoding: QUOTED-PRINTABLE

    Hi --

    On Mon, 5 Sep 2005, Dema wrote:

    > Not really. In this particular case, params is simply an accessor
    > method to the @params instance variable, not a local variable. So, in
    > practice, they=B4re equivalent.


    Oh, *that* params :)

    > The recommendation for using the params method, instead of accessing
    > the @params instance variable directly, is that it=B4s more uniform to
    > use the accessor method, since you can also do that from the view.


    You should be able to see your instance variables from the views too.


    David

    --=20
    David A. Black

    --8323328-357633517-1125848011=:1089--
    --8323328-357633517-1125848011=:1089--
    David A. Black, Sep 4, 2005
    #4
  5. Barry

    Barry Guest

    Thank you. That makes sense now. I found the following in
    ActionController::Base of actionpack that explains what you are
    describing,

    attr_accessor :params
    Barry, Sep 4, 2005
    #5
  6. > The recommendation for using the params method, instead of accessing
    > the @params instance variable directly, is that it=B4s 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?.
    --=20
    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
    David Heinemeier Hansson, Sep 4, 2005
    #6
  7. On Mon, Sep 05, 2005 at 01:26:44AM +0900, David Heinemeier Hansson wrote:
    > > 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?.


    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. <>
    Marcel Molina Jr., Sep 4, 2005
    #7
  8. 2005/9/4, David Heinemeier Hansson <>:
    > > The recommendation for using the params method, instead of accessing
    > > the @params instance variable directly, is that it=B4s more uniform to
    > > use the accessor method, since you can also do that from the view.

    >=20
    > 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?.
    >=20


    Is there a one-stop reference to the best practices for this sort of thing?

    Douglas
    Douglas Livingstone, Sep 5, 2005
    #8
  9. Ron Jeffries wrote:

    >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
    Devin Mullins, Sep 15, 2005
    #9
  10. Barry

    Ara.T.Howard Guest

    On Thu, 15 Sep 2005, Ron Jeffries wrote:

    > On Mon, 5 Sep 2005 01:26:44 +0900, David Heinemeier Hansson
    > <> wrote:
    >
    >>> 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?.

    >
    > 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
    ===============================================================================
    Ara.T.Howard, Sep 15, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. J. D.
    Replies:
    9
    Views:
    161
    Jamis Buck
    Nov 4, 2004
  2. Replies:
    6
    Views:
    175
    Michael Campbell
    Mar 17, 2005
  3. Greg McIntyre

    Rails + Amrita, Rails + XTemplate?

    Greg McIntyre, Apr 28, 2005, in forum: Ruby
    Replies:
    2
    Views:
    119
    Greg McIntyre
    Apr 28, 2005
  4. Michael Schuerig
    Replies:
    3
    Views:
    214
    Carl Youngblood
    Jun 17, 2005
  5. Brian Takita
    Replies:
    1
    Views:
    273
    Zed A. Shaw
    Sep 5, 2005
Loading...

Share This Page