-
Notifications
You must be signed in to change notification settings - Fork 4
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
Open Question: what to do about accessors? #4
Comments
I believe Web IDL does have an attribute concept that allows an interface to define attributes that end up exposed as getters/setters on the corresponding ECMAScript prototype objects. |
True, and I believe HTML does have some setters, despite 262 having none. That's an argument towards returning some kind of descriptor object - whether it's a full descriptor, or maybe just |
An alternative would be to prefix the property name with |
or If so, I think that could work very nicely. |
I think I prefer
|
The name isn't relevant, though, otherwise Also, there could be a function named "get" - i think |
I didn't express myself clearly. If Regarding syntax, an alternative to keep with the property access model would be |
Since the function name isn’t relevant, i strongly feel like your suggested string syntax isn’t viable. We can certainly bikeshed alternatives tho - i do very much like the suggestion to differentiate the strings for data vs accessor vs mutator properties. |
Since we're bikeshedding this, another alternative that also kinda solves the symbol issue is to take an array of path elements, which are either strings or symbols. E.g. However, it makes it less clear that |
I'd prefer to avoid the path array approach; it's added boilerplate and memory usage solely for explicitness (using a list of arguments would avoid the extra array, but wouldn't address the boilerplate concerns). So far the best options I can see are one of:
I like the third option because it avoids taxing the common case, and avoids the creation of a transient container for the get/set pair. |
That makes perfect sense to me — I have a strong preference for option three. There’s a descriptor option in my lib’s DSL (#d for descriptor, #g for get, #s for set), so I can speak in the past tense and say that I’ve only found it useful a small number of times and I wouldn’t include it again if I were recreating it now. At least in web platform API stuff, retrieving get/set is very common, maybe more common than data properties, so anything that keeps that smooth is 💖. |
When an intrinsic is an accessor property, the only use cases I have, and am aware of, require the
get
accessor function directly.Although when an intrinsic is a data property getIntrinsic will just return it, one option is that when it's an accessor property, getIntrinsic returns the getter. This is what https://npmjs.com/es-abstract does, and seems the easiest to me.
Another possibility would be returning a property descriptor, but then we'd have to do that for every intrinsic - and there's no use case i'm aware of for knowing the enumerability/configurability/writability of intrinsics, and no intrinsics currently have a setter.
The text was updated successfully, but these errors were encountered: