Skip to content
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

Factor out all ordinary object internal methods into OrdinaryXyz()? #91

Closed
domenic opened this issue Oct 19, 2015 · 9 comments
Closed
Labels

Comments

@domenic
Copy link
Member

domenic commented Oct 19, 2015

HTML needs to specify a couple exotic objects. (Web IDL also needs to do so, if it ever gets updated to ES2015.) In many cases the behavior is "if flag X is set, throw. Otherwise, do what an ordinary object would do."

For a couple internal methods, there are pre-existing abstract operations we can use: OrdinaryGetOwnProperty and OrdinaryDefineOwnProperty. But for all others, there are not.

I see two potential ways we could spec such exotic objects:

  1. Pull request ES to have OrdinaryXyz() abstract operation counterparts for all internal methods, and then use them: "If flag X is set, throw a TypeError. Otherwise, return OrdinarySetPrototypeOf(O, V)".
  2. Try to come up with some phrasing that is sufficiently precise. E.g.: "If flag X is set, throw a TypeError. Otherwise, return the result of the same algorithm as the [SetOwnProperty] method for ordinary objects, applied to object O with argument V."

Any advice? Is there a chance (1) could clean up parts of the ES spec that are currently duplicated?

/cc @annevk @allenwb

@anba
Copy link
Contributor

anba commented Oct 19, 2015

You could use the same language as in 9.4.4 Arguments Exotic Objects, for example:

Return the result of calling the default ordinary object [[SetPrototypeOf]] internal method (9.1.2) on O passing V as the argument.

[[Get]], [[Set]] and [[Delete]] for arguments objects use this wording to call the ordinary internal methods.

@domenic
Copy link
Member Author

domenic commented Oct 19, 2015

I guess that covers it; thanks!

@domenic domenic closed this as completed Oct 19, 2015
@annevk
Copy link
Member

annevk commented Oct 19, 2015

Is there a reason ECMAScript uses both patterns?

@bterlson
Copy link
Member

@annevk which patterns are you referring to?

@annevk
Copy link
Member

annevk commented Oct 20, 2015

What @anba mentioned and using OrdinaryInternalMethod abstract operations.

@annevk
Copy link
Member

annevk commented Oct 20, 2015

Also, if I say use "default ordinary object [[Get]] internal method", does that mean the [[GetOwnProperty]] call it does (and similar ones) are the normal non-overridden variants as well?

@allenwb
Copy link
Member

allenwb commented Oct 20, 2015

@annevk
Choice of how to do this is mostly a judgement call by the editor. delegating to OrdinaryX abstraction operation adds a level of indirection that make the normal case harder to read/understand. Using ""default ordinary object..." (and note a section reference is always included) only adds complexity at the "call site".

If you say "call the default ordinary object [[Get]] internal method" (and you need to include a section reference) you mean exactly and only that. If you say "call the [[GetOwnProperty internal method of obj" (or just say obj.[GetOwnProperty] ) you are going throw the meta-level dynamic dispatch to the specific [[GetOwnPrperty]] associated with obj.

@annevk
Copy link
Member

annevk commented Oct 21, 2015

It's still not clear that if you say "call the default ordinary object [[Get]] internal method" that means that the internal methods that that algorithm invokes, are also the default ordinary ones. At least not to me.

@allenwb
Copy link
Member

allenwb commented Oct 21, 2015

@annevk It is just referring to the internal methods specified in 9.1.

Arguably, the word "default" is redundant as any object that does not use the definitions in 9.1 is not an "ordinary object".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants