Description
This was originally posted as a part of #716, but is broken out here as its own issue.
While working on some Python code, I ended up needing to put together a pythonic representation of the message data model. While doing so, I encountered a few places where I could apply some simplifications to the data model with no loss of fidelity.
I think we should consider applying this change to how declarations are represented in the data model:
interface PatternMessage {
type: "message";
- declarations: Declaration[];
+ declarations: Map<string, Expression>;
+ statements: UnsupportedStatement[];
pattern: Pattern;
}
interface SelectMessage {
type: "select";
- declarations: Declaration[];
+ declarations: Map<string, Expression>;
+ statements: UnsupportedStatement[];
selectors: Expression[];
variants: Variant[];
}
-type Declaration = InputDeclaration | LocalDeclaration | UnsupportedStatement;
-interface InputDeclaration { type: "input", name: string, value: VariableExpression }
-interface LocalDeclaration { type: "local", name: string, value: Expression }As it's an error for multiple declarations to target the same variable name, and the resolution of a .input declaration doesn't actually differ from the resolution of a .local, we don't need to care about their syntactic differences or order in the data model.
We should also consider separating the representation of unsupported statements away from declarations, given that they're not necessarily at all related. Doing so would add a new restriction on future statements not being allowed to exhibit different valid behaviour based on their relative order w.r.t. .input and .local, but that doesn't seem too onerous.