From dba42768cd972cfa1a17c57797186576b3e36987 Mon Sep 17 00:00:00 2001 From: Arseny Kapoulkine Date: Mon, 15 Nov 2021 17:25:45 -0800 Subject: [PATCH] Update records.md --- rfcs/records.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfcs/records.md b/rfcs/records.md index a65a78fb..d5f0568e 100644 --- a/rfcs/records.md +++ b/rfcs/records.md @@ -45,7 +45,7 @@ introduce support for packed records where the table definition must use types a > TODO: It's going to be difficult to migrate to packed records. Is there anything we can do right now to keep this possibility open without enforcing types at runtime? -The rest of this proposal goes into syntax and semantics. +The rest of this proposal goes into syntax and semantics. The goal of this proposal is to solve the problem of object storage both for simple objects and for classes -- that is, if we add records we won't need to add classes. ### Record type @@ -167,6 +167,10 @@ Of course, the type checker also knows that the record type has the metatable wi > TODO: Does the type checker need to understand the internal structure of the shape so that type checking works across modules, or is simply modeling this > as a metatable sufficient? +### Object modeling + +> TODO: records don't support implementation inheritance and why it's a good thing + ## Drawbacks Adding a new data type that is cross-cutting (across syntax, semantics/compiler, semantics/type checking, and runtime) results in added complexity.