Shapes vs. lose Tabellen

Sie haben nun zwei Möglichkeiten, mit Record-Tables zu arbeiten: den loose Weg, den Sie schon immer in Lua verwendet haben, und declared shapes. Es lohnt sich vorauszuschauen, was Ihnen der jeweilige Ansatz bringt.

Eine loose Table akzeptiert alles. Diese Flexibilität hat ihren Preis: Buchstabieren Sie ein Feld falsch (user.nmae), erhalten Sie silently ein nil; vergessen Sie ein Feld, tritt der Fehler erst viel später zur Laufzeit an der Stelle auf, die zuerst auf diese Lücke zugreift:

local user = {name = "Ana", age = 20}
print(user.nmae) -- loose table: silently prints nil

Deklarieren Sie ein Shape, verschieben sich diese Fehler von der Laufzeit in die Bearbeitungszeit. Der Typechecker markiert den Tippfehler in dem Moment, in dem Sie ihn schreiben, Ihr Editor kann Feldnamen automatisch vervollständigen, und die type-Deklaration dient gleichzeitig als Dokumentation dessen, was die Table enthält:

type User = {name: string, age: number}
local user: User = {name = "Ana", age = 20}
print(user.nmae) -- ✗ type error: key 'nmae' not found in User

Wenn Sie von TypeScript kommen, beachten Sie, dass Luau kein interface-Schlüsselwort kennt — type deckt jedes Shape ab. Es gibt auch kein "Declaration Merging": Das Deklarieren zweier Typen mit demselben Namen im selben Scope führt zu einem error, sodass jedes Shape genau eine Definition hat.

Luaus Shapes sind strukturell: Jede Table mit den passenden Feldern der richtigen Typen stimmt überein, unabhängig davon, wo oder wie sie erstellt wurde. Und loose Tables haben weiterhin ihre Daseinsberechtigung — schnelle Skripte und wahrhaft dynamische Daten benötigen kein deklariertes Shape. Für alles, was zwischen Funktionen übergeben wird, fängt ein Shape Fehler jedoch ab, solange sie noch kostengünstig zu beheben sind.