I want to add a print in it method so that it prints the name of the spec. Where is it defined? I tried to look for the method's implementation but couldn't find it.
Both describe and it (xdescribe, fdescribe and so on as well) are defined in Env.js as you can see here
Now, in order to enhance it (no pun intended) you'd either have to override it or even provide your own wrapper in a global namespace and use that one.
Related
I have a class defined in a gem to which I am adding some methods via refinements (in Ruby 2.3.0). This class turns up in some Sinatra views (haml).
When I refer to these extra methods in a helper, there is not a problem. But in the view, I get an Undefined Method error.
Am I missing a trick, or is it that the using ... statement would need to go somewhere I just can't get to?
(Workaround: I can define helper methods to return the method on the object. But if I wanted to do that then I wouldn't have used refinements...)
The scope of refinement is determined lexically. Unless you rewrite the method inside haml that calls that method so that it becomes within the scope of the using command, you cannot use refinements. But I guess haml is internally using eval or something like that to evaluate the code you write in a haml file. In that case, it is impossible.
To show all methods defined by a particular class, but without methods that are defined in ancestors classes, I'm writing like this.
foo.methods - foo.class.superclass.methods
Is there better way to do it?
You can get instance methods with the following:
foo.class.instance_methods(false)
as documented in http://ruby-doc.org/core-1.9.3/Module.html#method-i-instance_methods.
The documentation for the parameter uses the term "superclasses" in describing what is included if the parameter is truthy, but based on my testing I believe all ancestor-provided methods are excluded/included based on this value, not just those from superclasses.
Lately I bumped into this very interesting post: http://opensoul.org/blog/archives/2011/02/07/concerning-activesupportconcern/ which walks through (and explains) the ActiveSupport::Concern source code.
A few questions arose, but the most important was this:
Obviously there's a method called append_features which (by the docs at least) says: "Ruby’s default implementation of this method will add constants, methods, and variables of this module to the base module".
I always thought that module works the same as classes in the sense of the method lookup chain - the only difference is that you can't instantiate objects from it, and that it's not defined as a 'superclass' of this class (since a module is not actually a class). meaning that when a class includes a module, the module is simply being added as a direct parent in the class's inheritance hierarchy, and as a result, methods which are missing in the including class, will be looked for at the module.
But if that's the case, then what does it mean that append_features actually "adds methods to the base module", which means that you can actually prevent this behaviour, by overriding this method (which ActiveSupport::Concern actually does).
Can someone create some order in my head?
Basically, the append_features is - or should be considered - a deeply internal ruby method.
The Module.include method is defined (in the "eval.c" file with the name of rb_mod_include) as a loop, which just calls mod.append_features (and then mod.included) for every Module argument passed to it.
The default append_features implementation (rb_mod_append_features in "eval.c" file), calls the rb_include_module, and this is the method which does the real job.
(Actually the really real job is done by the include_modules_at few lines below)
It means that you are perfectly right saying that you can prevent or break this basic ruby functionality by overriding the append_features (at least if you don't call the super).
The ActiveSupport::Concern actually calls the super, just in some cases it postpones the actual call until the "concerned" module is included by some "non-concerned" one.
It's usually better to override the included method instead of append_features. The included is defined as just "return nil", thus the probability of breaking anything is smaller. And that is what the documentation of the included method advices.
Sorry for the poor title, but I'm a bit lost.
I'm trying to figure out on which object/class live methods such as DelegateClass and what is the term for these types of methods. I'm reading Metaprogramming Ruby and, in the book, these methods are generically called Mimic Methods, but searching the internet for this gives all kinds of results, so I'm wondering if there's a better name for them.
I've checked the source code of DelegateClass and I assumed that it was added to Object, but it's not there. I can see the the classes Delegator and SimpleDelegator, which are in the same rb file, are added as constants (although I'm not sure how they are added).
Thanks!
Just found the answer. It's a private method in Object
ruby-1.9.2-p290 :033 > Object.private_instance_methods(false).grep /Dele/
=> [:DelegateClass]
edit
I found out that what I needed to understand is What is the current class? in a given context.
Look closer at the file.
def DelegateClass(superclass)
klass = Class.new(Delegator)
...
and use
method(:DelegateClass).owner
to find the class where it sits. As mentioned in the comments private instance methods on Module contain anything defined on Object.
So no, DelegateClass() is not a special method in any way except for being called in uppercase (which makes it look like a constant). It just returns an anonymous class created on-the-spot that can be inherited from.
I am new to Ruby, and have a gem that I am making to interact with a JSONRPC API and basically all calls and responses are similar enough, that every API call can be handled with one function, like:
Module::api_command('APINamespace.NamespaceMethod')
but I would like to also (for convenience sake) be able to do:
Module::APINamespace.NamespaceMethod
Is there any reason not to do this by using Module.const_missing to return a dummy class that has a method_missing which will allow passing the call from Module::APINamespace.NamespaceMethod to Module::api_command('APINamespace.NamespaceMethod')
Is there a more elegant or civilized way to do this?
Yes, I'm sorry, but to my mind that hack is ridiculous. :)
First of all, i'm assuming that your api_command method is actually invoking methods on the APINamespace module, as implied by this line: Module::api_command('APINamespace.NamespaceMethod')
Given the above, why not just set a constant equal to APINamespace in your module?
MyModule::APINamespace = ::APINamespace
MyModule::APINamespace.NamespaceMethod()
UPDATE:
I'm still not entirely understanding your situation, but perhaps this:
module MyModule
def self.const_missing(c)
Object.const_get(c)
end
end
Now you can invoke any top-level constant as if it was defined on your module; say there was a module called StrangeAPI at top-level, if you use the hack above, you can now invoke its methods as follows:
MyModule::StrangeAPI.Blah()
Is this what you want?