-
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
More tightly describe name
processing in the spec
#2
Comments
Something I noticed is with the (existing ECMA262) spec text that says:
One thing not clear about this is what to do about getters/setters, currently the spec does specify a number of getters such as There's also |
Oh also we need to consider what happens with values that are in a prototype chain, e.g. does By allowing it we allow potentially a lot of ways to access a given intrinsic, this may or may not be desirable. This is particularly tricky with intrinsics that may be exposed in new ways over time, for example currently there is Because of this sort've thing, we might want to cleanup the intrinsic table a bit to be more consistent, not sure what would be best to do here but perhaps something like introducing |
On Symbol methods, the intention is definitely to allow something like For getters, indeed we’ll need to pull out the getter function automatically, thanks for calling that out. Values in a prototype chain do not work, because |
The “FooPrototype” intrinsic notation is legacy and will not be supported by this API. |
This sounds fine to me, but what should be done with APIs that have no corresponding global "constructor"? For example while Although |
That's a good point. Prior to Looks like I'll need to audit the entire list of intrinsics and figure out what makes sense to support or not. |
|
All the lengths and names, we don’t need to worry about. |
That makes sense, I figured they wouldn’t be included. The list is showing every distinct path except for those which, if followed further, would cycle infinitely (in which case it only expands the shortest+alphabetically earliest). I didn’t know if primitive-value data properties would be considered addressable or if they would be but only selectively:
|
Properties of top-level namespaces are all included, but otherwise i don’t think any intrinsics are non-objects. We’d also not traverse through any |
Cool — I assumed no Is it possible/desirable for there to just be a finite set of “addresses”? It seems there are currently around ~600 unique intrinsic objects. With traversing |
I'd prefer to find an algorithmic way of describing the list, rather than hardcoding it. |
That makes sense — but afaict, an algorithmic explanation for what addresses exist can still produce a finite set of possible keys, obviating the need for (an implementation) to really parse & interpret the input as a DSL (even though it would act like one). |
So the rules perhaps could be:
Traversal is:
Thoughts? |
Sounds great! Later I’ll try adjusting the traversal script I used to verify that it still reaches all of the same objects as it did with the more naive pass (modulo non-standard members) when those rules are (effectively) in play — but I’m pretty sure what you described does the trick. The resulting set of address keys should be both intuitive & “incidentally” finite. |
For reference, Endo/SES has some logic to crawl the global and remove anything that isn't in an allowlist which takes a similar form to a registry of intrinsics. |
The spec text here needs to be better; I'm not sure how yet.
The text was updated successfully, but these errors were encountered: