Recent searches
Search options
The `Class.new.tap { |klass| klass.include(context) }.new` is necessary so the resulting context object gets access to both the module's instance methods *and* it's constants. If anyone knows of a better way to wrap a module into an instance context for IRB, feel free to correct me here.
I seem to remember the old school way was to create a new Object.new, then access it's meta-class via `class << obj; self; end`, and then include the module into the meta-class, which was a bit too magical, but prevented `self.inspect` from returning `#<#<Class: ...>>` which looks confusing vs. regular old `#<Object:...>`.
I'm sort of leaning towards just overriding `obj.inspect` to return `#<TheModule>` to indicate that you are in fact in an instance of an Object that included some other module's stuff.
Cool trick I just discovered, transparently forward `const_missing` of an object to another module without adding another line to the backtrace:
obj.singleton_class.define_singleton_method(:const_missing,&mod.method(:const_missing))
@postmodern I think we can officially call that `singleton_class` now. I don't think it's magical and I used it extensively in a lot of places, notably mocking library muack. In a different context, but I also used it in an interactive environment: https://github.com/godfat/rib/blob/rib-1.6.1/lib/rib/shell.rb#L94
On topic, I voted for `#<TheModule>` as well because I think inspect should always be precise. If one wants to know what exactly it is, one can look at ancestors
Also defining `self.inspect` is defining on the singleton class