形状 vs 柔軟なテーブル

これで、レコード table を扱う方法が2つあります。Luaでこれまで使ってきた loose な方法と、宣言された形状です。それぞれにどんな利点があるのか、ここで立ち止まって確認しておく価値があります。

loose な table は何でも受け入れます。その柔軟性には代償があります。フィールド名を間違えると（user.nmae）、nil が silently 返されます。フィールドを忘れると、バグは実行時に、離れた場所で、その空白に最初に触れたコードの中で初めて表面化します。

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

形状を宣言すると、こうしたミスは実行時から編集時へと移ります。入力した瞬間にチェッカーが誤りを指摘し、エディターはフィールド名を自動補完でき、type 宣言は table に何が含まれるかを示すドキュメントの役割も果たします。

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

TypeScript から来た場合は、Luau には interface キーワードがないことに注意してください。すべての形状を type が処理します。また、「宣言のマージ」もありません。同じスコープで同じ名前の型を2つ宣言するとエラーになるため、それぞれの形状には定義が1つだけ存在します。

Luau の形状は構造的です。正しい型の正しいフィールドを持つ table なら、どこで、どのように作成されたかに関係なく一致します。一方、loose な table にも使い道があります。簡単なスクリプトや、本当に動的なデータには、宣言された形状は必要ありません。ただし、関数間で渡されるものについては、まだ修正しやすい段階で形状がミスを見つけてくれます。