-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
strings option 5 - Use branded strings with extended prototype #7
base: main
Are you sure you want to change the base?
Conversation
|
||
For example, `'á'[0]` would return `'á'` in EcmaScript, but would return `0xC3` in TEALScript because it gets the first byte (and this character is a two byte sequence). | ||
|
||
To solve this, we could extend the prototype of `string` to have byte-specific functions. For example, `.getByte(i)` instead of `[i]` and `.sliceBytes(i)` instead of `.slice(i)`. If a developer tries to use the character-based functions, the compiler can throw an error. We can also show an error in the IDE via TypeScript plugins. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To solve this, we could extend the prototype of `string` to have byte-specific functions. For example, `.getByte(i)` instead of `[i]` and `.sliceBytes(i)` instead of `.slice(i)`. If a developer tries to use the character-based functions, the compiler can throw an error. We can also show an error in the IDE via TypeScript plugins. | |
To work around this, we could extend the prototype of `string` to have byte-specific functions. For example, `.getByte(i)` instead of `[i]` and `.sliceBytes(i)` instead of `.slice(i)`. If a developer tries to use the character-based functions, the compiler can throw an error. We can also show an error in the IDE via TypeScript plugins. |
@@ -189,8 +204,8 @@ We should select an appropriate name for the type representing an AVM string. It | |||
- ✅ very obvious what it is | |||
- ✅ obvious how it differs to `string` | |||
|
|||
|
|||
Option 5 would be the preferred option if we were to prioritize developer experience whereas option 4 would be best if we priotized control over the prototype. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prioritize developer experience
This feels a little subjective. What aspects of the developer experience are prioritized by this option? The obvious one I can see is saving a couple of characters in declaration, but at the expense of having to explicitly type variables
const demo: bytes = "my bytes"
vs.
const demo = Str`my bytes`
someFunc("my bytes")
vs.
someFunc(Str`my bytes`)
Are there any others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "a couple of characters in declaration" is a bit reductive of the impact it has on the developer experience. When developers use strings they expect to be able to put literals between quotation marks. Adding any friction to that can be a bit jarring. We saw this with PyTeal Bytes
constructor frequently.
That being said, I agree that "developer experience" is too subjective, so I've changed it to familiarity
This PR adds a new option to the bytes and strings ADR. The idea comes after talking to a developer that had a strong reaction to needing custom constructors to strings. This option maintains semantic compatability by not allowing character-based functions to be used on strings and instead adding byte-based functions to the prototype.
Since a new option has been added, I have reverted the "Selected option" to TBD