Closed mattbrictson closed 11 years ago
Hmm. It doesn't seem like calling introspection methods like is_a?
and respond_to?
should trigger the deprecation warning, but maybe it's just applied to all methods.
Yes, the deprecation warning seems to be triggered on all methods except inspect
. For example, respond_to?
:
>> ::RAILS_CACHE.respond_to?(:parse)
DEPRECATION WARNING: RAILS_CACHE is deprecated! Use ::Rails.cache instead. (called from irb_binding at (irb):1)
=> false
Here is the basic implementation from activesupport:
class DeprecationProxy #:nodoc:
def self.new(*args, &block)
object = args.first
return object unless object
super
end
instance_methods.each { |m| undef_method m unless m =~ /^__|^object_id$/ }
# Don't give a deprecation warning on inspect since test/unit and error
# logs rely on it for diagnostics.
def inspect
target.inspect
end
private
def method_missing(called, *args, &block)
warn caller, called, args
target.__send__(called, *args, &block)
end
end
Should commander work around this, or do you think I should raise this as an issue with activesupport?
@mbrictson could you try this commit and confirm if it fixes the problem? It works for me. https://github.com/visionmedia/commander/commit/b475b6e6cf44400ed48808d42160833b850b5e22
Yes, that fixes the deprecation warning for me. Thanks!
Cool, I've just released 4.1.5 with this fix incorporated.
If I do
require "commander"
inside a Rails 4 app, I get this message:This seems to be a side-effect of how activesupport implements its deprecation mechanism. Commander goes through all global constants and calls
respond_to?
on them, triggering the deprecation warning for theRAILS_CACHE
constant.I'm not sure if this is a commander or an activesupport issue.
Here's the full trace in IRB: