You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In chapter 12, when we implement VisitClassStmt in the interpreter, the book has us bind the class in two steps - first define the name (whose value is null), and later reassign that name to the LoxClass we create. The claim is: "That two-stage variable binding process allows references to the class inside its own methods."
That "define it first" idea makes sense for the resolver, where we resolve the methods inline (so the class name must exist upfront). But in the interpreter, we don't evaluate the methods between the two steps, so it should be safe to omit the first step and just bind the class one time, after we've created the corresponding LoxClass. I tried that, and my test cases still work. For example:
class foo {
bar() {
print foo;
}
}
foo().bar(); // prints "foo class"
The text was updated successfully, but these errors were encountered:
In chapter 12, when we implement VisitClassStmt in the interpreter, the book has us bind the class in two steps - first define the name (whose value is null), and later reassign that name to the LoxClass we create. The claim is: "That two-stage variable binding process allows references to the class inside its own methods."
That "define it first" idea makes sense for the resolver, where we resolve the methods inline (so the class name must exist upfront). But in the interpreter, we don't evaluate the methods between the two steps, so it should be safe to omit the first step and just bind the class one time, after we've created the corresponding LoxClass. I tried that, and my test cases still work. For example:
The text was updated successfully, but these errors were encountered: