ruby - Use application class instance variable inside get block -
i using sinatra , have code:
class app < sinatra::base configure @logger = logger.new "./log" end @logger.info "app started" #this line works "/info" @logger.info "/info inquired" #this not work , complain @logger nilclass end end why @logger inside block gives nil object? how can use @logger in case?
ps. if use class variable @@logger, code above works. why instance variable not working in case?
instance variables attach whatever object self @ time instance variables spring existence.
on face of things, these values self:
class app < sinatra::base #in here, self=app #when block executes, sees value self existed in #the surrounding scope @ time block created: configure #a block #so...in here self=app @logger = logger.new "./log" end @logger.info "app started" #this line works "/info" #a block #similarly, in here self=app @logger.info "/info inquired" #@logger nilclass end end based on state of things, right confused: looks when configure() executes block passed it, @logger spring existence , attach app, when get() calls block passed it, @logger instance variable refer instance variable attached app.
but...ruby offers ways change value of self block sees when block executes. here example:
p = proc.new { puts self } p.call class dog def initialize(a_proc) #in here, self dog instance instance_eval &a_proc end end dog.new p --output:-- main #<dog:0x000001009b6080> based on error, have suspect sinatra must employing ruby tricks change self when executes block passed get().
how can know this?
ruby wild west of programming languages, can't ever know going happen unless @ source code or docs if exist. source code pretty convoluted. found in docs:
some knowledge of sinatra’s internal design required write extensions. section provides high level overview of classes , idioms @ core of sinatra’s design.
sinatra has 2 distinct modes of use extensions should aware of:
the “classic” style, applications defined on main / top-level – of examples , documentation target usage. classic applications single-file, standalone apps run directly command line or minimal rackup file. when extension required in classic application, expectation extension functionality should present without additional setup on application developers part (like included/extending modules).
the “modular” style, sinatra::base subclassed explicitly , application defined within subclass’s scope. these applications bundled libraries , used components within larger rack-based system. modular applications must include desired extensions explicitly calling register extensionmodule within application’s class scope.
most extensions relevant both styles care must taken extension authors ensure extensions right thing under each style. extension api (sinatra.register , sinatra.helpers) provided extension authors task.
important: following notes on sinatra::base , sinatra::application provided background - extension authors should not need modify these classes directly.
sinatra::base the sinatra::base class provides context evaluation in sinatra application. top-level dslish stuff exists in class scope while request-level stuff exists @ instance scope.
applications defined within class scope of sinatra::base subclass. “dsl” (e.g., get, post, before, configure, set, etc.) set of class methods defined on sinatra::base. extending dsl achieved adding class methods sinatra::base or 1 of subclasses. however, base classes should not extended extend; sinatra.register method (described below) provided task.
requests evaluated within new sinatra::base instance – routes, before filters, views, helpers, , error pages share same context. default set of request-level helper methods (e.g, erb, haml, halt, content_type, etc.) simple instance methods defined on sinatra::base or within modules included in sinatra::base. providing new functionality @ request level achieved adding instance methods sinatra::base.
as dsl extensions, helper modules should not added directly sinatra::base extension authors include; sinatra.helpers method (described below) provided task.
Comments
Post a Comment