-
Notifications
You must be signed in to change notification settings - Fork 165
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
Parsing updated ecma262 intrinsic notation #897
Comments
Search & replace should work here and in HTML and should not break anything. Though I'm not sure where they should link now? The one loss here is that now it's no longer clear for implementers looking at ECMAScript which of these they need to support and instead they'll also have to look at IDL and HTML. This was discussed in tc39/ecma262#1105 (comment) and the idea there was to create abstract algorithms for where algorithms needed to be shared and intrinsics for when you need identity. Is that still a thing that's being considered? |
I don't quite understand the concern. What's more difficult about the IDL spec than the HTML spec? They're pretty analogous, with HTML's dependencies section being replaced by a structured metadata block in https://github.com/heycam/webidl/blob/9208c17edcfb2ee6eaebc6663d3e3155b3091a34/index.bs#L88-L96 |
@domenic one question i have: this repo contains "review_drafts" which use the legacy intrinsic style. should i update those too, or leave them alone? @annevk the links go to the same places.
I'm a bit confused by this; if an implementor is implementing a web browser, they'd have to do that anyways. |
You're probably talking about the HTML repo? Those should stay unchanged. |
ok thanks, i'll make the PR for this repo first and we can go from there :-) hopefully it's straightforward and i'm just being overly cautious by asking first. |
Awesome. Thank you for the proactive work on this. |
Follows tc39/ecma262#1376, and prevents problems in the future when the non-dotted forms are deleted. Closes #897.
@ljharb consider an implementer of a JS engine who wants to make it suitable for embedding in various hosts, but doesn't want to read through all the various standards applicable to each of the hosts. |
Such an implementer would likely then need to optimistically cache all originals as potential intrinsics, yes. |
Hi!
In the ecma262 spec, we've added a new intrinsic notation form that will avoid unbounded growth of our list of intrinsics.
Specifically, things like
%ArrayPrototype%
and%ObjProto_valueOf%
should now be represented as%Array.prototype%
and%Object.prototype.valueOf%
, respectively.Our intention is to delete the "legacy" forms entirely in favor of the dotted forms. I wanted to file a PR on https://github.com/whatwg/html, but then realized I might need to file one on https://github.com/heycam/webidl/blob/master/index.bs#L88-L110 first (I filed w3c/webidl2.js#480 before this, and was directed here).
I'm happy to do the work to update spec text (and for HTML, I have a branch prepared already), but I doubt I'm qualified to do the work here. Could someone help give me pointers as to what the next steps should be?
In particular, one approach that occurred to me (that I could handle!) would be to add to the current "hardcoded legacy intrinsics mentioned in HTML" the list of "hardcoded dotted intrinsics mentioned in HTML". That seems simplest, but has the downside (one which already exists now) that a PR would still have to be made here to support autolinking a new intrinsic. The ideal approach (which perhaps could be made later) would be one that figures out from any
%A.b%
which section it should link to.The text was updated successfully, but these errors were encountered: