From 5d1efac9aa826ed927743067e4854c7c90ffe60d Mon Sep 17 00:00:00 2001 From: aaron Date: Thu, 15 Aug 2024 13:06:41 -0700 Subject: [PATCH] Update examples to match revised API --- docs/user-defined-type-functions.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/user-defined-type-functions.md b/docs/user-defined-type-functions.md index 71dde15..1b8fd5a 100644 --- a/docs/user-defined-type-functions.md +++ b/docs/user-defined-type-functions.md @@ -29,9 +29,13 @@ type function rawget(tbl, key) error("first parameter must be a table type!") end - for k, v in tbl:getprops() do + for k, v in tbl:properties() do if k == key then - return v + if v.read ~= v.write then + error("mismatched read/write types found for the property") + end + + return v.read end end @@ -211,11 +215,11 @@ end This is a reasonable design in its own right, and was used in the initial prototype of user-defined type functions because of its relative ease of implementation. We decided against continuing with it, however, because it makes it more difficult to apply basic well-formedness restrictions to the interface of type functions. For instance, we want all union types to have at least two elements to them (i.e. to be a non-trivial union), which would be harder to enforce with the table design since developers could just write `{type = "union", components = {{type = "string"}}}`. More generally, this design makes the creation of new types at runtime messier and more prone to errors since there's a greater surface for minor typos and misplaced braces to impact the program. -### Compile-time Interpreter +### Compile-Time Interpreter Many languages implement an additional interpreter for evaluating expressions at compile-time. This approach has its benefits, such as allowing us to completely isolate analysis and runtime and allowing developers to write type functions in a syntax that potentially deviates from Luau's runtime syntax (e.g. supporting constructing intersection and union types using `&` and `|`). This has two main downsides: (1) the implementation required is higher complexity and carries a greater maintenance burden, and (2) the design against one of the stated goals for type functions. We want the experience of writing type functions to feel intrinsically familiar to developers and for the semantics to be the same as ordinary Luau code. Since Luau is already designed around being embeddable, we prefer to use the existing VM and add a new userdata instead. -### More Built-in Type Functions +### More Built-In Type Functions Another alternative is to create more built-in type functions that cover a wider range of programming patterns. This approach clearly lacks the flexibility of fully user-defined type functions because type manipulation would still be limited to the predefined set of type functions designed by the Luau team. Furthermore, continuously expanding the set of built-in type functions leads to bloat and complexity within the language, making it harder to keep in your head, harder to maintain, and ultimately running against Luau's core philosophy of simple, general-purpose primitives and a small standard library.