Rack rack → 1.0

Comments and changes to this ticket

• 

  Ryan Tomayko December 28th, 2008 @ 09:47 AM

  Something like this is necessary at minimum, IMO:

  http://groups.google.com/group/r...

  
  def Rack::Request.new(env)
    unless env["rack.request"] and env["rack.request"].is_a?(self)
      env["rack.request"] = super(env)
    end
    env["rack.request"]
  end
  

  Another option would be back off of using new or using alias_method to keep the non-memoizing new around:

  
  class Rack::Request
    class << self ; alias_method :new!, :new ; end
    def self.new(env)
      self['rack.request'] ||= super
    end
  end
  

  People would have to be careful to call new! on subclasses if they don't want memoization, though.

• You flagged this item as spam.
  

  Matt Todd December 28th, 2008 @ 09:57 AM

  • Title changed from “Rack::Request Subclassing and Memoization Issues” to “[PATCH] Rack::Request Subclassing and Memoization Issues”

  Changed the method to test for the existence and for the class equality.

  http://github.com/mtodd/rack/com...

  ed32e29176c24043d666ca56d1127a714a95d811 8acbf2b6f875f20893083b451d34ac72912b7a71

  This is mostly useful for subclasses that define the same self.new method.

  I like this implementation more than adding a new! method because it behaves normally for all classes that expect to leave its mark on the object.

  Plus, subclasses should behave mostly the same everywhere else env['rack.input'] is expected to behave like Rack::Request.

• 

  Ryan Tomayko December 29th, 2008 @ 10:43 AM

  I guess we're still in the process of ironing out how and when Rack::Request should be used vs. the env hash but I'm a big +1 for mtodd's patch.

• 

  josh February 1st, 2009 @ 03:59 AM

  • Milestone set to “1.0”
  • Assigned user set to “josh”
  • State changed from “new” to “resolved”

  http://github.com/rack/rack/comm...