how do you know the classNames which you created?

[kawakami]

Hello.

When developing the codes to comprehend "type", how do you know your own className?

eg.
Suppose I create my own class named Test1 and declare it in Test2.jack as a "classVarDec".
like..
---
class Test2 {
  field Test1 test1;
}
---

When compiling Test2.jack, I guess that the compiler does not know if Test1 exists.
Or Do I have to scan the directory BEFORE compiling to know what types (file names of *.vm) exist?

Thanks in advance.

[ivant]

The compiler, as specified in the course, doesn't need to know the other class names. It just produces Test2.vm which references Test1 (or any of the standard library classes for that matter). These classes or functions inside them may not exist yet, but the compiler can produce correct code.

What you lose in this scenario is error checking. Maybe you misspelled a class or method name. Or you call it with wrong parameters or a number of other problems which one would expect the compiler to detect and report will be ignored. But you will detect them if and when you translate the .vm files into assembly.

In a way, this is similar to how C compilers work. When you compile test1.c file the compiler produces the so called object file: test1.o. It can reference functions, which are defined in other parts of the program or in external libraries. They may not yet be written, but the compiler can still generate the object file. To produce the executable file, one calls the linker with all the participating object files and libraries. The linker will detect and report any discrepancies like the ones described above.



N.B. There are major differences between the object files and the VM files though. Object files are essentially compiled to machine language, and have additional data about the functions and variables it defines and about the the external ones it need resolved.

[kawakami]

Thank you very much for your quick reply!
I've been trying to throw compilation error when unknown className is found.
Now it's clear.

Thanks a lot.

[WBahn]

One of the things that the authors specify in the text is that you may assume that all input is correct.

They've worked hard to make this true for the files they've provided, but of course this is unlikely to be true for all of the programs that you write as you go through the course. So what they mean is that, if the input files are not correct in some way, the tools that you write have no obligation to do anything reasonable -- crashing is fine, producing output that is complete gibberish is fine.

This is a direct consequence of cramming a course with as broad a scope as this one into a one semester course. A lot of depth and general good software engineering practices have to be left behind to get through everything.

But, you may find it very educational to try to address some of these issues in more reasonable ways. In part, that involves asking at what point they should be addressed.

For instance, the compiler has the information it needs to determine if a function or method of a given class is called within that class without having been defined within that class. But it doesn't have the information it needs to make that determining for functions/methods belonging to other classes. So at what point in the compilation process from Jack to Hack is that information available? How is it available? Are there things your tools could do to make that information more accessible?