consistency with access to the value that is being decorated
trusktr opened this issue · 3 comments
The new spec says
They can provide access to the value that is being decorated, via metadata. For public values, they can do this via the name of the value. For private values, they receive accessor functions which they can then choose to share.
For sake of consistency, can we make it an accessor for both public and private values?
This will make it easier to write shorter code that works in either case, as opposed to more complicated conditional branching.
Additionally ES-like languages that compile to WebAssembly, like AssemblyScript, do not support arbitrary string indexing because of strict types and lack of the dynamic parts.
Although I know ES is not meant to cover AssemblyScript (or vice versa), but ES being a guide for AS, it might be good to take into account the future of WebAssembly via ES-like languages. Accessors work a lot better in that case.
Regardless, consistency is still the most valuable for dev experience IMO.
I think maybe the term "accessor" is confusing here, since that refers to getters; if it's basically a "thunk" - a function you invoke with no arguments, and receive the result - then that seems like a reasonable consistency.
I think this would be a reasonable change, the main reason we didn't do this previously was for performance, so we'd be creating fewer functions/objects overall, but I agree the DX would be worse and it's not clear it would be that much less performant. We already create several functions per decorator context object, so not sure two more would be that much of an issue.