|
| 1 | +<!-- |
| 2 | +SPDX-FileCopyrightText: 2023 Friedrich-Alexander-Universitat Erlangen-Nurnberg |
| 3 | +
|
| 4 | +SPDX-License-Identifier: AGPL-3.0-only |
| 5 | +--> |
| 6 | + |
| 7 | +# RFC 0021: Sheet row access syntax |
| 8 | + |
| 9 | +| | | |
| 10 | +|---|---| |
| 11 | +| Feature Tag | `sheet-row-access-syntax` | |
| 12 | +| Status | `ACCEPTED` | |
| 13 | +| Responsible | `jrentlez` | |
| 14 | +<!-- |
| 15 | + Status Overview: |
| 16 | + - DRAFT: The RFC is not ready for a review and currently under change. Feel free to already ask for feedback on the structure and contents at this stage. |
| 17 | + - DISCUSSION: The RFC is open for discussion. Usually, we open a PR to trigger discussions. |
| 18 | + - ACCEPTED: The RFC was accepted. Create issues to prepare implementation of the RFC. |
| 19 | + - REJECTED: The RFC was rejected. If another revision emerges, switch to status DRAFT. |
| 20 | +--> |
| 21 | + |
| 22 | +## Summary |
| 23 | + |
| 24 | +This RFC removes an unnecessary definition of RFC 0020 regarding sheet row |
| 25 | +access. |
| 26 | + |
| 27 | +## Motivation |
| 28 | + |
| 29 | +The `[]` syntax introduced in RFC 0020 is a completely new concept to new users. |
| 30 | + |
| 31 | +## Explanation |
| 32 | + |
| 33 | +Below is the current way of accessing the values of a sheet row, as specified |
| 34 | +in RFC 0020: |
| 35 | + |
| 36 | +```jayvee |
| 37 | +transform Parser { |
| 38 | + from row oftype SheetRow; |
| 39 | + to coord oftype Coordinate; |
| 40 | +
|
| 41 | + coord: { |
| 42 | + x: asInteger row["x"], |
| 43 | + y: asInteger row[2], |
| 44 | + } |
| 45 | +} |
| 46 | +``` |
| 47 | + |
| 48 | +### `.` replaces `[]` |
| 49 | + |
| 50 | +`row[2]` is a familiar syntax for accessing a collection. |
| 51 | +But at a deeper level, `[]` is a function that takes a collection and a |
| 52 | +"location" and returns the collection's value at the "location". |
| 53 | + |
| 54 | +Jayvee already has a concept for this, operators. |
| 55 | +As a consequence, the `[]` syntax is replaced with the new binary operator `.`. |
| 56 | + |
| 57 | +```jayvee |
| 58 | +coord: { |
| 59 | + // Both notations (with and without spaces around `.`) are valid. |
| 60 | + x: asInteger (row . "x"), |
| 61 | + y: asInteger (row.2), |
| 62 | +} |
| 63 | +``` |
| 64 | + |
| 65 | +## Drawbacks |
| 66 | + |
| 67 | +- Parentheses may be mistaken as a function call |
| 68 | + |
| 69 | +## Alternatives |
| 70 | + |
| 71 | +### `.`'s name |
| 72 | + |
| 73 | +We could use a "speaking name" for `.` e.g. `cellInColumn`. |
| 74 | + |
| 75 | +Pros: |
| 76 | + - If the name is well chosen, it's obvious what the operator does |
| 77 | + |
| 78 | +Cons: |
| 79 | + - `cellInColumn` would be used very frequently, creating lots of visual |
| 80 | + "noise". |
| 81 | + - We are committing to the singular function of this operator and cannot |
| 82 | + expand it in the future |
| 83 | + |
| 84 | +### `.` precedence |
| 85 | + |
| 86 | +`.` has the highest precedence out of all binary and ternary operators, but a |
| 87 | +lower precedence than unary operators (RFC 0009). |
| 88 | +This results in braces being necessary (see example above). |
| 89 | +We could make an exception and give `.` the highest precedence out of all |
| 90 | +operators, which would enable the following: |
| 91 | + |
| 92 | +```jayvee |
| 93 | +someValue: { |
| 94 | + x: asInteger row . "x", |
| 95 | + y: asInteger row.2, |
| 96 | + z: asInteger row."x", |
| 97 | +} |
| 98 | +``` |
| 99 | + |
| 100 | +## Possible Future Changes/Enhancements |
| 101 | + |
| 102 | +- We may be able to unify the `.` operator and the nested property access from |
| 103 | + RFC 0018. |
0 commit comments