Is there any good way to find where is a function being called in our codebase ?
There is a gem called Starscope (disclaimer: I am the author) which can list function calls in ruby code, among other things. It isn't perfect, since it can't handle crazy meta-programming, but it will find all the normal calls to a given function.
gem: https://rubygems.org/gems/starscope
github: https://github.com/eapache/starscope
user guide: https://github.com/eapache/starscope/blob/master/doc/USER_GUIDE.md
edit: Luc's answer is entirely accurate as far as it goes; I wrote Starscope specifically to be "Cscope for Ruby".
With ctags, no. It references functions declarations and definitions, not their uses.
Then it depends on the language.
cscope can help with C, but not with C++. With C++, you should have a look at clang based solutions : there is clang_indexer (and its many forks) (see vim-clang to integrate it in vim), but I did found a few quirks ; it seems YouCompleteMe does a few things related to code indexation (as it provides GotoImplementation/Declaration commands).
For other languages, you may have dedicated plugins. But for sure, there is always grep (and many plugins that integrates it)
Besides Ruby-Doc, what sources are best to take some examples and tutorials from, especially about Tk/Tile in Ruby? I found myself more normal with
http://www.tutorialspoint.com/ruby/ruby_tk_guide.htm
http://www.perfectxml.com/syngress/ruby/Page1.asp
but the information is pretty vague, and there is not so much to learn from. I had to consult multiple sources. I found two books from O'Reilly Media:
http://shop.oreilly.com/product/9781565924987.do
http://shop.oreilly.com/product/9781565924338.do
but don't know if it's the right thing to start with. Even Lynda.com doesn't have anything interesting to look into.
The best site I know of for learning Tk is TkDocs, which has a tutorial that covers multiple languages including Ruby. (To just see the Ruby version, set the language in the side-bar. Alternatively, leave it at the default of “All Languages” to find out how other languages bind the same library; the differences can be illuminating…)
(Mathematica version: 8.0.4)
lst = Names["Internal`*"];
Length[lst]
Pick[lst, StringMatchQ[lst, "*Bag*"]]
gives
293
{"Internal`Bag", "Internal`BagLength", "Internal`BagPart", "Internal`StuffBag"}
The Mathematica guidebook for programming By Michael Trott, page 494 says on the Internal context
"But similar to Experimental` context, no guarantee exists that the behavior and syntax of the functions will still be available in later versions of Mathematica"
Also, here is a mention of Bag functions:
Implementing a Quadtree in Mathematica
But since I've seen number of Mathematica experts here suggest Internal`Bag functions and use them themselves, I am assuming it would be sort of safe to use them in actual code? and if so, I have the following question:
Where can I find a more official description of these functions (the API, etc..) like one finds in documenation center? There is nothing now about them now
??Internal`Bag
Internal`Bag
Attributes[Internal`Bag]={Protected}
If I am to start using them, I find it hard to learn about new functions by just looking at some examples and trial and error to see what they do. I wonder if someone here might have a more complete and self contained document on the use of these, describe the API and such more than what is out there already or a link to such place.
The Internal context is exactly what its name says: Meant for internal use by Wolfram developers.
This means, among other things, the following things hold about anything you might find in there:
You most likely won't be able to find any official documentation on it, as it's not meant to be used by the public.
It's not necessarily as robust about invalid arguments. (Crashing the kernel can easily happen on some of them.)
The API may change without notice.
The function may disappear completely without notice.
Now, in practice some of them may be reasonably stable, but I would strongly advise you to steer away from them. Using undocumented APIs can easily leave you in for a lot of pain and a nasty surprise in the future.
I have been C/C++/VBNET programmer for a long time. Now Ruby advanced concept is attracting me. So I decided to learn how to use it.But the "Behavior" of Ruby used to confused me. I usually feel like can't completely control my Ruby program.
Can you help me get clearly about this ?
(Maybe some of your favorite guide about "Ideas" and "Styles" in Ruby may help >:D< . Thank)
Ruby is quite an unusual programming language if you are more used to static/declarative style languages like C/C++.
I suspect it's the highly dynamic nature of the language which is causing you a problem, it can be difficult to get your head around this when you encounter it for the first time after having used only the more static languages. Ideas like Duck Typing can seem weird if you are used to declaring variables as strict types before use.
I would thoroughly recommend working your way through one of the excellent books about ruby that are out there. Don't just mess around writing code without really understanding the concepts.
Personally I really liked "The Ruby Programming Language" from O'Reilly, but I have experiance of a lot of different languages so I'm used to some of the more dynamic features in Ruby.
However you may prefer to start with something less terse such as Dave Thomas' "Programming Ruby" (make sure you get the 1.9 version).
Work through one of these books, do the examples, play around with the code. That way you will get a thorough understanding of the language.
Best of luck. Once you get your head around it, Ruby can be a very powerful language.
I think that the book Design Patterns in Ruby might help you. The first chapter describes the syntax of Ruby (which I guess that you won't need), but the rest of the book goes through the classic design patterns and shows you a Ruby way of approaching them. It's very clearly written and I learned a lot about Ruby idioms from it.
If you can talk to a Rubyist then that will probably help a lot - from experience, a code review or pairing session with someone else can get you over mental blocks better than anything else. If you don't know anyone, try writing some code then post a link to it to the Ruby Talk mailing list with questions. This is a very friendly community, and people are happy to help.
I recommend reading Why's Poignant Guide to Ruby. It will open your mind to the wonders of working in a dynamic language. Or it will piss you off with its cartoons of talking foxes. Either way it will change your thinking about Ruby :)
I'm slowly moving from PHP5 to Python on some personal projects, and I'm currently loving the experience. Before choosing to go down the Python route I looked at Ruby. What I did notice from the ruby community was that monkey-patching was both common and highly-regarded. I also came across a lot of horror stories regarding the trials of debugging ruby s/w because someone included a relatively harmless library to do a little job but which patched some heavily used core object without telling anyone.
I chose Python for (among other reasons) its cleaner syntax and the fact that it could do everything Ruby can. Python is making OO click much better than PHP ever has, and I'm reading more and more on OO principles to enhance this better understanding.
This evening I've been reading about Robert Martin's SOLID principles:
Single responsibility principle,
Open/closed principle,
Liskov substitution principle,
Interface segregation principle, and
Dependency inversion principle
I'm currently up to O: SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION.
My head's in a spin over the conflict between ensuring consistency in OO design and the whole monkey-patching thing. I understand that its possible to do monkey-patching in Python. I also understand that being "pythonic" is to follow common, well-tested, oop best-practices & principles.
What I'd like to know is the community's opinion on the two opposing subjects; how they interoperate, when its best to use one over the other, whether the monkey-patching should be done at all... hopefully you can provide a resolution to the matter for me.
There's a difference between monkey-patching (overwriting or modifying pre-existing methods) and simple addition of new methods. I think the latter is perfectly fine, and the former should be looked at suspiciously, but I'm still in favour of keeping it.
I've encountered quite a few those problems where a third party extension monkeypatches the core libraries and breaks things, and they really do suck. Unfortunately, they all invariably seem stem from the the third party extension developers taking the path of least resistance, rather than thinking about how to actually build their solutions properly.
This sucks, but it's no more the fault of monkey patching than it's the fault of knife makers that people sometimes cut themselves.
The only times I've ever seen legitimate need for monkey patching is to work around bugs in third party or core libraries. For this alone, it's priceless, and I really would be disappointed if they removed the ability to do it.
Timeline of a bug in a C# program we had:
Read strange bug reports and trace problem to a minor bug in a CLR library.
Invest days coming up with a workaround involving catching exceptions in strange places and lots of hacks which compromises the code a lot
Spend days extricating hacky workaround when Microsoft release a service pack
Timeline of a bug in a rails program we had:
Read strange bug reports and trace problem to a minor bug in a ruby standard library
Spend 15 minutes performing minor monkey-patch to remove bug from ruby library, and place guards around it to trip if it's run on the wrong version of ruby.
Carry on with normal coding.
Simply delete monkeypatch later when next version of ruby is released.
The bugfixing process looks similar, except with monkeypatching, it's a 15 minute solution, and a 5-second 'extraction' whereas without it, pain and suffering ensues.
PS: The following example is "technically" monkeypatching, but is it "morally" monkeypatching? I'm not changing any behaviour - this is more or less just doing AOP in ruby...
class SomeClass
alias original_dostuff dostuff
def dostuff
# extra stuff, eg logging, opening a transaction, etc
original_dostuff
end
end
In my view, monkeypatching is useful to have but something that can be abused. People tend to discover it and feel like it should be used in every situation, where perhaps a mixin or other construct may be more appropriate.
I don't think it's something that you should outlaw, it's just something that the Ruby guys like to use. You can do similar things with Python but the community has taken the stance that things should be simpler and more obvious.
Monkey patching is not ruby-explicit, its done all over javascript too, with negative (IMO) effects.
My personal opinion is monkey patching should only be done to
a) Add functionality to an old version of a language which is available in the new version of the language which you need.
b) When there is no other "logical" place for it.
There are many many easy ways to make monkey patching really awful, such as the ability to change how basic functions such as ADDITION work.
My stance is, if you can avoid it, do so.
If you can avoid it in a nice way, kudos to you.
If you can't avoid it, get the opinion of 200 people because you probably just have not thought about it hard enough.
My pet hate is mootools extending the function object. Yes, you can do this. Instead of people just learning how javascript works:
setTimeout(function(){
foo(args);
}, 5000 );
There was added a new method to every function object, ( yes, im not joking ) so that functions now have their own functions.
foo.delay( 5000 , args );
Which had the additional effect of this sort of crap being valid:
foo.delay.delay( 500, [ 500, args ] );
And on like that ad infinitum.
The result? You no longer have a library, and a language, your langauge bows to the library and if the library happens to be in scope, you no longer have a language, and you cant just do things the way that they were done when you learn the language, and instead have to learn a new subset of commands just to not have it fall flat on its face ( at the cost of excessive slowdowns! )
may i note that foo.delay also returned an object, with its own methods, so you could do
x = foo.delay( 500, args );
x.clear();
and even
x.clear.delay(10);
which may sound overly useful, ... but you have to take into consideration the massive overhead used to make this viable.
clearTimeout(x);
SO HARD!
(Disclaimer: its been a while since I used moo, and have tried to forget it, and function names/structure may be incorrect. This is not an API reference. Please check their site for details ( sorry, their API reference sucks! ))
Mokeypatching is generally wrong. Create a proper subclass and add the methods.
I've used monkeypatching once in production code.
The issue is that REST uses GET, POST, PUT and DELETE. But the Django test client only offers GET and POST. I've monkeypatched methods for PUT (like POST) and DELETE (like GET).
Because of the tight binding between Django client and the Django test driver, it seemed easiest to monkeypatch it to support full REST testing.
You may find enlightening this discussion about Ruby's open classes and the Open-Closed Principle.
Even though I like Ruby, I feel monkey-patching is a tool of last resort to get things done. All things being equal, I prefer using traditional OO techniques with a sprinkle of functional programming goodness.
In my eyes, monkey-patching is one form of AOP. The article Aspect-Oriented Design Principles: Lessons from Object-Oriented Design (PDF) gives some ideas of how SOLID and other OOP principles can be applied to AOP.
My first thought is that monkey-patching violates OCP, since clients of a class should be able to expect that class to work consistently.
Monkey-patching is just plain wrong, IMHO. I've not come across the open/closed principle you mention before, but it's a principle I've long held myself, I agree with it 100%. I think of monkey-patching as a code-smell on a larger scale, a coding-philosophy-smell, as it were.