Given a package of classes and their interfaces, would you ever want to look within, to see how the classes work? Indeed, there are several reasons not to look beneath the method signatures of the classes. By relying strictly on the interface and not on how the code supports it, you free your code from dependencies on how another package works. The separation of interface and execution is a cornerstone of several advances in applied computer science, especially distributed computing and component development.
On the other hand, professional developers often want to look beneath the signatures of methods they rely on. In the general case, this examination may help you to understand in detail the exact performance of a method. The code is the final arbiter of what a class actually does.
In the case of parsers, there are many reasons to look under the hood to see how the fundamental classes work. When you write your own parsers, you may encounter surprises and subtleties that pull you into looking at the mechanics of these classes. You may find that you want to write a faster engine, or you may want to add a new type of terminal or a new subhierarchy of Parser . Even if you have no intention of tinkering with the workings of the fundamental parser classes, familiarizing yourself with their operation will increase your understanding of how to use them.