The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).
However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.
The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).
More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
Currently, we have NotA and NotAn, to be used dependent on whether the
following word begins with a vowel or not. To avoid this, change the
wording on NotA to be independent of this context.
This should fix the flaky tests of test-js.
It also fixes the tests when running with the -g flag since the values
will not be garbage collected too soon.
The keyword accessors all have the same function body in the spec,
except for the Intl.Locale method they invoke. This generates those
properties in the same manner as RegExp.prototype.
Intl.Locale.prototype.calendar
Intl.Locale.prototype.caseFirst
Intl.Locale.prototype.collation
Intl.Locale.prototype.hourCycle
Intl.Locale.prototype.numberingSystem
The exception is Intl.Locale.prototype.numeric, which will be defined
separately because it is a boolean value.
This isn't particularly testable yet without the Intl.Locale constructor
but having this defined will make testing the constructor possible. So
more specific tests for this prototype will come later.
In the IsStructurallyValidLanguageTag AO, we of course cannot assume the
variants are canonicalized to lower-case yet, because canonicalization
hasn't happened yet.
ErrorType::IntlInvalidCode has almost exactly the same message as
ErrorType::OptionIsNotValidValue. Remove it, as all uses of the former
are semantically interchangeable with the latter.
