Class members leave the lexical chain (§13.17, §13.18, §13.22)

[kaidesu]

Overview

§15's #2, #3 and #4. It started as #2 and #4 — one diagnostic on the member-declaration path — and a review question reframed it:

a method named math is reached as this.math(), so why should it collide with a top-level math import at all?

It shouldn't. Rejecting the declaration made an author work around a collision that has no reason to exist. So the second commit replaces that diagnostic with a scoping change, in the one direction §13.17 was already forcing — which is why #2 and #3 turned out to be the same question, not two.

A method is a member, not a name in scope. A method body — and a field initializer — now resolves through the scope its class was declared in, rather than the class body's scope. Members still live in class.Environment, which LookupMember reads for this.x() and super.x(); that table is simply no longer a lexical scope.

import "ghost:math" as math

class Theme {
    load() { return math.floor(3.7) }   // 3 — the module
    math(role) { return role }          // reached as this.math()
}

Both work. §13.22 dissolves rather than being guarded.

What each callout gets

§13.22 — no diagnostic. Gone with it: shadowedModuleError, isImportedModule, Environment.GetEnclosing and the object.Map.Module flag — along with the question they existed to answer, is this binding "really" an imported module? That had no honest answer for a Ghost source module bound as a plain Map, and a rule that has to classify what it shadows is doing the wrong job.

§13.17 — closed by the same change. A bare sibling call is now a plain Name fault at the call site, and undefined recognises a name that is a member of the running class:

show() { return describe() }
// before: name error at describe()'s `this`, in correct code, in another method
// after:  name error here, at `describe`
//         help: `describe` is a member of `W`; reach it through `this.describe`

§13.18 — untouched, still a Syntax fault at the second declaration. A field and a method sharing a name is a genuine collision; it is unrelated to lexical scoping.

Field initializers needed the same treatment — the other path into a class body, evaluated per instance, which reproduced §13.22 exactly (size = math.floor(2.7) beside a method named math) and would have survived the diagnostic entirely.

A bonus

§14 decision 9 recorded, as a live cost of walking assignment, that "a local named scale would rebind a sibling method named scale". Members are out of the chain now, so that collision is gone:

class A {
    scale() { return 1 }
    run() { scale = 5 return this.scale() }
}
// before: type error - `A.scale` is a number, which cannot be called
// after:  1

§13.13 and decision 9 are updated to say so, with a test pinning it.

Breaking change

A bare sibling call to a method that never touches this used to work — the narrowest possible version of the feature, and precisely why the defect survived to 1.0 — and now raises. One test pinned it (TestClassMemberResolution, updated to this.).

All 41 programs in examples/ and all 132 cases of Studio's suite are unchanged; neither codebase used the bare form, and Studio's own CLAUDE.md already mandates this.method(). mud.gs differs only in frame count inside its timeout, as in the previous PRs.

§8.8 now states the JavaScript rule the rest of Ghost's class syntax already follows — new, extends, constructor, keyword-less methods — where bare sibling calls don't exist either. The bare form was a Ruby-ism inside a JS-shaped class.

Verification

• evaluator/class_members_test.go: the field/method collision both ways and in a trait; a method sharing a name with a scheme import, a Ghost source module, a trait, and a field initializer, with the method still reachable; bare sibling calls for a callee that touches this and one that doesn't; the help text; the local-vs-sibling-method case; and the eight shapes that must not be rejected.
• go build ./..., go vet ./..., gofmt -l ., go test ./... all clean.

§14 decision 12 records the call and its cost. Next on §15 is #5 (§13.16), the one open design decision (§14 decision 10).

🤖 Generated with Claude Code

https://claude.ai/code/session_01EGsNMRiKwWmvoizxD619zA