How compilers know about other classes and their properties?

Question

I'm writing my first programming language that is object orientated and so far so good with create a single 'class'. But, let's say I want to have to classes, say ClassA and ClassB. Provided these two have nothing to do with each other then all is good. However, say ClassA creates a ClassB--this poses 2 related questions:

-How would the compiler know when compiling ClassA that ClassB even exists, and, if it does, how does it know it's properties?

My thoughts thus far had been: instead of compiling each class at a time (i.e scan, parse and generate code) each "file (not really file, per se, but a "class") do I need to scan + parse each first, then generate code for all?

Answer 1

Different languages (and thus compilers) approach this differently.

In the C family, the different modules have a corresponding header file that is used while building the object. The header files provide information on the size of the object and what functions or methods exists that may be invoked.

In java, the compiler is aware of things on its classpath and inspects those object to link against them (verifying that methods exists, have the right number of arguments, etc...). Java may also link dynamically at runtime loading in other classes that it doesn't know anything about when it was compiled. See Class.forName for one example of dynamic loading.

Both options are quite valid and have their own set of advantages and disadvantages. Providing header files some see as cumbersome and violating DRY. On the other hand, if you don't have header files libraries need to be inspectable by the compiler and linker - a .so or .dll likely won't have enough information in it to properly instantiate the objects or validate the method calls (and would be machine dependent).

Answer 2

In your case it might be a good idea to pause the compilation of ClassA until all it's dependencies (i.e. ClassB) have been compiled, or build a dependency graph and start compiling from the top down. It's completely dependent on how you intend to handle classes in your compiler. e.g. Will you have a sizeof(ClassB) functionality? Well, how can you do that if you haven't compiled ClassB yet?

Answer 3

Practically speaking, with Java, the IDE's look at a whole program at once; when ClassB is referenced, the IDE compiler will look at it. Everything, including the libraries, is one complete whole. Once the program is ready, you can change classpaths, swap in and out individual .class files, and switch library versions. You could also compile individual .java files without using the IDE (or somehow avoiding it's checks). The result does not need to be consistent at all, and if it's not you will get run-time exceptions. (One of the many things an IDE is trying to do for you is turn run-time errors into compile-time, or rather, edit-time, errors.)

C#'s about the same, and I don't think C and C++ are really that different, in that what the Java and C# IDE's are doing is just creating C/C++-style headers for you behind the scenes.