W3C

Web IDL 第2版

2016 年 6 月 23 日付 W3C 編集者草案

このバージョン
http://heycam.github.io/webidl/
最新発行バージョン
http://www.w3.org/TR/WebIDL-1/
第1版
http://www.w3.org/TR/WebIDL/
以前のバージョン
http://www.w3.org/TR/2012/CR-WebIDL-20120419/
http://www.w3.org/TR/2012/WD-WebIDL-20120207/
http://www.w3.org/TR/2011/WD-WebIDL-20110927/
http://www.w3.org/TR/2011/WD-WebIDL-20110712/
http://www.w3.org/TR/2010/WD-WebIDL-20101021/
http://www.w3.org/TR/2008/WD-WebIDL-20081219/
http://www.w3.org/TR/2008/WD-WebIDL-20080829/
http://www.w3.org/TR/2008/WD-DOM-Bindings-20080410/
http://www.w3.org/TR/2007/WD-DOM-Bindings-20071017/
Participate:
Send feedback to public-script-coord@w3.org (archive) or file a bug (open bugs)
編集
Cameron McCormack, Mozilla Corporation <cam@mcc.id.au>
Boris Zbarsky, Mozilla Corporation <bzbarsky@mit.edu>
Copyright © 2016 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

要約

この文書は、 Web ブラウザへの実装を目的とするインタフェースを記述するためのインタフェース定義言語, Web IDL を定義する。 Web IDL は、 Web プラットフォームにおける, 共通のスクリプト オブジェクトの挙動を,より容易く指定できるようするために、いくつもの特色機能を備えた IDL の変種である。 この文書では、 Web IDL で記述されるインタフェースを, ECMAScript 実行環境の構成子に対応付ける方法についても,詳細に渡り述べられる。 この文書は、[ 既に発行済みの仕様,および 新たに発行され, この文書を参照する仕様 ]の適合インタフェース実装が,相互運用可能になるための、実装者にとっての指針になるものと期待されている。 This document defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. Web IDL is an IDL variant with a number of features that allow the behavior of common script objects in the web platform to be specified more readily. How interfaces described with Web IDL correspond to constructs within ECMAScript execution environments is also detailed in this document. It is expected that this document acts as a guide to implementors of already-published specifications, and that newly published specifications reference this document to ensure conforming implementations of interfaces are interoperable.

この文書の位置付け

この節では… 【 以下、この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

この文書は Web IDL (第2版)仕様の 2016 年 6 月 23 日付 編集者草案( Editor’s Draft )です。 この文書についてコメントがあれば public-script-coord@w3.orgアーカイブ )宛に送られるよう願います。 This document is the 23 June 2016 Editor’s Draft of the Web IDL (Second Edition) specification. Please send comments about this document to public-script-coord@w3.org (archived).

これは Web IDL の,第1版 勧告候補から分岐された第2版です。 この第2版には、勧告策定の進行を遅滞させずには第1版に含めれないような,新たな特色機能が含められています。 This is the Second Edition of Web IDL, branched off from the Candidate Recommendation of the First Edition. This Second Edition includes new features that could not have been added to the First Edition without delaying its progress along the Recommendation track.

【 第1版と 最新発行バージョン である “Level 1” バージョンとは別物であることに注意。 第1版より新たな部分のほとんどは、 ECMAScript 6 による新機能に対応するものであり,したがって第1版との下位互換性もほぼ保たれる形で策定されているものと見られるが、特に,例外オブジェクトに関する記述は一新され、配列( array )型も凍結配列( frozen array )型に置き換えられている。 また、少数の用語も第1版から変更されている( “attribute (属性)” → “regular attribute (正則属性)” など)。 】

【 “Level 1” バージョンとの相違点は(その仕様からの引用): Level 1 バージョンは、メインである編集者草案の一部であって,実装され試験された安定的と見なされている部分を含む。 実装者は、最新の更新を含むこの編集者草案を参照されたし(…以下略)。 この訳では、 Level 1 に含まれていない主な部分には,この文と同じ背景色によるスタイル付けを施してある(煩雑になるので、細部まで施されてはいない)。

この文書は W3C Interaction DomainWeb Platform Working Group により制作されました。 この文書に加えられた変更は GitHub のコミットログ: 最近の変更点, より以前の変更点 から閲覧できます。 This document is produced by the Web Platform Working Group in the W3C Interaction Domain. Changes made to this document can be found in the specification’s commit log on GitHub: recent changes, older changes.

この仕様の bug tracker もご覧ください。 There is a bug tracker for the specification.

1. 序

~INFORMATIVE

W3C により発行される技術報告に含められる~programming言語~ifcは、概して Object Management Group による~IDL( Interface Definition Language ) `OMGIDL$r を利用して記述されていた。 この~IDLは、これらの~ifcを,言語から独立な方式で記述する手段を提供する。 通例,その種の文書には、~IDLで記述された~ifcを[ 所与の言語 ]の構成子に対応付ける方法について,詳細を述べる、言語束縛についての追加の付録が含められる。 ◎ Technical reports published by the W3C that include programming language interfaces have typically been described using the Object Management Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a means to describe these interfaces in a language independent manner. Usually, additional language binding appendices are included in such documents which detail how the interfaces described with the IDL correspond to constructs in the given language.

しかしながら、 Web 上で最も共通的に利用されている言語, ~JSに対しては、これらの仕様における言語束縛は,終始~低い~~精度で指定されていたため、相互運用性の課題も生じていた。 加えて、それぞれの仕様が同じ基本的な情報を述べなければならない — 例えば、 ~IDLで記述される DOM ~ifcが~JS大域~objの~propに対応していることや, `unsigned long$T ~IDL型が~JSの `Number^t 型に対応付けられることなど。 ◎ However, the bindings in these specifications for the language most commonly used on the web, ECMAScript, are consistently specified with low enough precision as to result in interoperability issues. In addition, each specification must describe the same basic information, such as DOM interfaces described in IDL corresponding to properties on the ECMAScript global object, or the unsigned long IDL type mapping to the Number type in ECMAScript.

この仕様は、 Web API のための~ifcを定義する仕様で利用できる, OMG ~IDLに似た~IDL言語を定義する。 この~IDLには、以前は注釈文による記述を要していた共通の機能性を~supportするために,いくつもの拡張が加えられた。 加えて、 ECMAScript Edition 6 のための,精確な言語束縛も与えられた。 ◎ This specification defines an IDL language similar to OMG IDL for use by specifications that define interfaces for Web APIs. A number of extensions are given to the IDL to support common functionality that previously must have been written in prose. In addition, precise language bindings for ECMAScript Edition 6 are given.

1.1. 表記規約

この文書では、次の表記規約/~styleが利用される: ◎ The following typographic conventions are used in this document:

【 “†” が付与されているものは、この訳による追加の~style。 】

  • 用語の定義: `用語例@ ◎ Defining instances of terms: example term
  • この文書で定義される用語へのリンク: `用語例$ ◎ Links to terms defined in this document: example term
  • 他の文書で定義される用語へのリンク: example term ◎ Links to terms defined in other documents: example term
  • 文法~記号: `ExampleGrammarSymbol^g ◎ Grammar symbols: ExampleGrammarSymbol
  • 文法の~literal ~keyword/~tok(終端~記号): 平文の中では `exampleKeyword^c, ~IDL文法片の中では引用符で括って `exampleToken^sym †
  • ~IDL型:`ExampleIDLType^T,
    ~IDL~ifc~mb:`ExampleIDLMember^M,
    ~IDL値:`ExampleIDLValue^V
  • ~JS型:`ExampleESType^t,
    ~JS値:`ExampleESValue^v ◎ IDL and ECMAScript types: ExampleType
  • ~JS内的[~prop/~meth/~slot]: `ExamplePropertyOrMethodOrSlot^es †
  • ~JS抽象演算: ExampleAbstractOperation
  • ~code片: `a = b + obj.f()^c ◎ Code snippets: a = b + obj.f()
  • Unicode 文字: `U+0030 DIGIT ZERO ("0")^char ◎ Unicode characters: U+0030 DIGIT ZERO ("0")
  • 拡張属性: `ExampleExtendedAttribute^x ◎ Extended attributes: [ExampleExtendedAttribute]
  • 注釈文や~algoにおける変数~名: %exampleVariableName ◎ Variable names in prose and algorithms: exampleVariableName.
  • 文字列~literal: `example string literal^l †
  • モデルを定義するために利用される仮想の定数~値: `定数~例^C †
  • 各~algoでは、~JS~completion~recordを unwrap するための[ ! 記法および ? 記法 ]も含め, ~JS仕様の規約 が利用される。 ◎ Algorithms use the conventions of the ECMAScript specification, including the ! and ? notation for unwrapping completion records.
  • ~IDL構文の参考例: ◎ IDL informal syntax examples:

    interface `identifier^mk {
      `interface-members…^mk
    };
    

    (周囲の注釈文の中で論の対象にされている部分は, mark 要素で`強調される^mk(~styleはブラウザに依存する)。) ◎ (Red text is used to highlight specific parts of the syntax discussed in surrounding prose.)

  • ~IDL文法~片: ◎ IDL grammar snippets:

    [5] `ExampleGrammarSymbol^g
    OtherSymbol "sometoken" | AnotherSymbol | ε // nothing

    (各~文法~規則の左側には参照~用の番号が振られる。) ◎ (Each grammar rule is assigned a number for reference, shown on the left.)

  • 規定でない注記: ◎ Non-normative notes:

    これは注記。 ◎ This is a note.

  • 規定でない例: ◎ Non-normative examples:

    これは例。 ◎ This is an example.

  • 規定の警告: ◎ Normative warnings:

    これは警告。 ◎ This is a warning.

  • ~code~block: ◎ Code blocks:

    // これは~IDL~code~block。
    interface Example {
      attribute long something;
    };
    
    // これは~JS~code~block。
    window.onload = function() { window.alert("loaded"); };
    

【日本語訳に特有の表記規約】

この訳では,アルゴリズムの記述に次の記号を用いる : := (~~定義), :← (~~初期化), ← (~~代入), ~EQ, ~NEQ (~~比較),
~IF, ~ELSE, ~ELIF, ~WHILE, ~FOR ~EACH (…), ~BREAK, ~CONTINUE, ~RET, ~THROW, ~TRY, ~CATCH (~~実行制御)

これらのうち,次のもの以外の意味や定義の詳細は,~SYMBOL_DEF_REFを~~参照。

  • ~THROW, ~TRY, ~CATCH は、もっぱら~JS言語束縛において利用される(定義はリンク先を~~参照)。
  • := は :← と同じ意味に解釈されても不都合は無いが、意味合いは異なる:

    %var := %value 新たな記号 %var の~~導入とその値の %value による定義を表す(原文 “let var to …” )。
    %var :← %value 新たな変数 %var の~~導入とその値の %value による初期化-を表す(原文 “initialize” )。 := との相違は, %var の値が後で変更され得る所( … のように見受けられるが、原文をそのまま反映しているだけなので,~~例外はあるかもしれない)

この仕様の中の用語の一部は、定訳が無いため,訳者が適当に対訳をあてがっている。 ウィンドウ下端に対訳の切り替え機能がある。

2. 適合性

図式, 例, 注記, および “参考” と記された節を除く,この仕様のすべては規定である。 ◎ Everything in this specification is normative except for diagrams, examples, notes and sections marked as being informative.

この文書における~keyword[ “〜~MUST” = MUST / “〜しては~MUST_NOT” = MUST_NOT / “~REQUIRED” = REQUIRED / “〜する~SHOULD” = SHOULD / “〜する~SHOULD_NOT” = SHOULD NOT / “〜しても~MAY” = MAY ]は、 RFC 文書にて要件の程度を指示するために利用される~keyword `RFC2119$r の記述に則って解釈されるものとする。 ◎ The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels [RFC2119].

この仕様では、次に挙げる主体が適合性の対象になるものと定義される: ◎ The following conformance classes are defined by this specification:

`適合~IDL片の集合@◎conforming set of IDL fragments
`~IDL片$の集合は、全体として,この仕様にて~IDL片に適用される[ “〜~MUST_NOT” , “~REQUIRED” ~levelの判定基準 ]をすべて満たすとき,`適合~IDL片の集合$になる。 ◎ A set of IDL fragments is considered to be a conforming set of IDL fragments if, taken together, they satisfy all of the MUST-, REQUIRED- and SHALL-level criteria in this specification that apply to IDL fragments.
`適合~実装@◎conforming implementation
~UAは、自身が~supportするすべての言語束縛において,この仕様により その実装に適用される,すべての “〜~MUST_NOT” , “~REQUIRED” ~levelの判定基準を満たすとき, `適合~IDL片の集合$に対する`適合~実装$であるとされる。 ◎ A user agent is considered to be a conforming implementation relative to a conforming set of IDL fragments if it satisfies all of the MUST-, REQUIRED- and SHALL-level criteria in this specification that apply to implementations for all language bindings that the user agent supports.
`適合~JS実装@◎conforming ECMAScript implementation
~UAは、この仕様にて~JS言語束縛の実装に適用されるすべての “〜~MUST_NOT” , “~REQUIRED” ~levelの判定基準を満たすとき, `適合~IDL片の集合$に対する`適合~JS実装$であるとされる。 ◎ A user agent is considered to be a conforming ECMAScript implementation relative to a conforming set of IDL fragments if it satisfies all of the MUST-, REQUIRED- and SHALL-level criteria in this specification that apply to implementations for the ECMAScript language binding.

3. ~ifc定義~言語

この節では、 Web ~platform API のための~ifcを定義するために利用できる言語, Web IDL について述べる。 Web API を定義する仕様は、[ その仕様が定義する API のための~ifc(~objが表出し得る状態と挙動) ]を記述する,1つ以上の `~IDL片@ を含み得る。 `~IDL片$は、文法~記号 `Definitions$g に合致する,定義の並びである。 実装が~supportする `~IDL片$の集合は、順序付けられない。 完全な文法と利用される記法の説明については, 付録 A を見よ。 ◎ This section describes a language, Web IDL, which can be used to define interfaces for APIs in the Web platform. A specification that defines Web APIs can include one or more IDL fragments that describe the interfaces (the state and behavior that objects can exhibit) for the APIs defined by that specification. An IDL fragment is a sequence of definitions that matches the Definitions grammar symbol. The set of IDL fragments that an implementation supports is not ordered. See Appendix A for the complete grammar and an explanation of the notation used.

`~IDL片$に現れ得る `定義@ には、次の種類がある: `~ifc$, `部分的~ifc定義$, `辞書$, `部分的~辞書~定義$, `~typedef$, `~implements文$ 。 これらはすべて後続の節にて定義される。 ◎ The different kinds of definitions that can appear in an IDL fragment are: interfaces, partial interface definitions, dictionaries, partial dictionary definitions, typedefs and implements statements. These are all defined in the following sections.

各`定義$( `Definition$g に合致)の前には、[ `拡張属性$の~list( `ExtendedAttributeList$g に合致) ]を置くことができる — それらは、その定義が,言語束縛において どう取扱われるかを制御する。 この仕様が定義する拡張属性の,どの言語束縛にも通用する部分については `idl-extended-attributes$sec にて論じられ、~JS言語束縛~特有の部分については `es-extended-attributes$sec にて論じられる。 ◎ Each definition (matching Definition) can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how the definition will be handled in language bindings. The extended attributes defined by this specification that are language binding agnostic are discussed in section 3.11, while those specific to the ECMAScript language binding are discussed in section 4.3.

[`extended-attributes^mk]
interface `identifier^i {
  `interface-members…^i
};
-Definitions -Definition -CallbackOrInterface

`~IDL片$の例を示す: ◎ The following is an example of an IDL fragment.

interface Paint { };

interface SolidColor : Paint {
  attribute double red;
  attribute double green;
  attribute double blue;
};

interface Pattern : Paint {
  attribute DOMString imageURL;
};

[Constructor]
interface GraphicalWindow {
  readonly attribute unsigned long width;
  readonly attribute unsigned long height;

  attribute Paint currentPaint;

  void drawRectangle(double x, double y, double width, double height);

  void drawText(double x, double y, DOMString text);
};

ここでは、4個の`~ifc$が定義されている。 `GraphicalWindow^T ~ifcには、 2個の`読専$ `属性$, 1個の~writableな属性, 2個の`演算$ が定義されている。 `GraphicalWindow^T ~ifcを実装する~objは、 利用されている個別の言語に適切な方式で,これらの属性と演算を公開することになる。 ◎ Here, four interfaces are being defined. The GraphicalWindow interface has two read only attributes, one writable attribute, and two operations defined on it. Objects that implement the GraphicalWindow interface will expose these attributes and operations in a manner appropriate to the particular language being used.

~JSにおいては、~IDL~ifc上の属性/演算は、すべての `GraphicalWindow^T ~objにおいて,その原型~obj上の ~accessor~prop / `Function^t 値~data-prop として,公開されることになる。 `GraphicalWindow^T を実装する各~JS~objは、その原型鎖の中にその原型~objを持つことになる。 ◎ In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor properties and the operations as Function-valued data properties on a prototype object for all GraphicalWindow objects; each ECMAScript object that implements GraphicalWindow will have that prototype object in its prototype chain.

`GraphicalWindow^T 上に現れる `Constructor$x は`拡張属性$である。 この拡張属性により、 `new GraphicalWindow()^c の~callに対し,この~ifcを実装する新たな~objを返すような構築子が、~JS実装に存在することになる。 ◎ The [Constructor] that appears on GraphicalWindow is an extended attribute. This extended attribute causes a constructor to exist in ECMAScript implementations, so that calling new GraphicalWindow() would return a new object that implemented the interface.

3.1. 名前(識別子)

どの[ `~ifc$, `部分的~ifc定義$, `辞書$, `部分的~辞書~定義$, `列挙$, `呼戻~関数$, `~typedef$ ]も(これらは総称して `有名~定義@ と呼ばれる), および どの[ `定数$, `属性$, `辞書~mb$ ]も、何らかの`演算$を行うための `識別子@ を持つ。 識別子はその宣言~内のどこかに位置する `identifier$g ~tokから決定される: ◎ Every interface, partial interface definition, dictionary, partial dictionary definition, enumeration, callback function and typedef (together called named definitions) and every constant, attribute, and dictionary member has an identifier, as do some operations. The identifier is determined by an identifier token somewhere in the declaration:

  • `有名~定義$に対しては、~keyword: `interface^c, `dictionary^c, `enum^c, `callback^c の直後に現れる `identifier$g ~tokがその定義の識別子を決定する。 ◎ For named definitions, the identifier token that appears directly after the interface, dictionary, enum or callback keyword determines the identifier of that definition.

    interface `interface-identifier^mk { `interface-members…^i };
    partial interface `interface-identifier^mk { `interface-members…^i };
    dictionary `dictionary-identifier^mk { `dictionary-members…^i };
    partial dictionary `dictionary-identifier^mk { `dictionary-members…^i };
    enum `enumeration-identifier^mk { `enumeration-values…^i };
    callback `callback-identifier^mk = `callback-signature^i;
    
  • `属性$, `~typedef$, `辞書~mb$ に対しては、宣言の末尾の~semicolonの前に位置する最後の `identifier$g ~tokが識別子を決定する。 ◎ For attributes, typedefs and dictionary members, the final identifier token before the semicolon at the end of the declaration determines the identifier.

    interface `identifier^i {
      attribute `type^i `attribute-identifier^mk;
    };
    
    typedef `type^i `typedef-identifier^mk;
    
    dictionary `identifier^i {
      `type^i `dictionary-member-identifier^mk;
    };
    
  • `定数$に対しては、等号の前に位置する `identifier$g ~tokが識別子を決定する。 ◎ For constants, the identifier token before the equals sign determines the identifier.

    const `type^i `constant-identifier^mk = `value^i;
    
  • `演算$に対しては、返値型の後,かつ左~丸括弧の前に現れる `identifier$g ~tok( `OperationRest$g の中の文法~記号 `OptionalIdentifier$g の部分として合致) が、その演算の識別子を決定する。 そのような `identifier$g ~tokが無い場合、その演算は識別子を持たない。 ◎ For operations, the identifier token that appears after the return type but before the opening parenthesis (that is, one that is matched as part of the OptionalIdentifier grammar symbol in an OperationRest) determines the identifier of the operation. If there is no such identifier token, then the operation does not have an identifier.

    `return-type^i `operation-identifier^mk(`arguments…^i);
    

[ 取得子や設定子などの, 特殊な種類の演算 ]を宣言する演算は、識別子を持たないことがある。 ◎ Operations can have no identifier when they are being used to declare a special kind of operation, such as a getter or setter.

これらの構成子のすべてにおいて、 `identifier$g ~tokから先頭の `U+005F LOW LINE ("_")^char 文字を(もし在れば)除去した値が`識別子$になる。 ◎ For all of these constructs, the identifier is the value of the identifier token with any leading U+005F LOW LINE ("_") character (underscore) removed.

先頭の `"_"^char は、識別子を~escapeして,予約済みの語と見誤られなくするために利用される。 例えば、 `interface^l という名前を持つ~ifcも定義できる。 先頭の `"_"^char は識別子の~escapeを外す際に落とされる。 ◎ A leading "_" is used to escape an identifier from looking like a reserved word so that, for example, an interface named “interface” can be defined. The leading "_" is dropped to unescape the identifier.

演算~引数がとり得る識別子は、もう少し広い集合になる。 演算の宣言においては、引数の識別子はその型の直後に指定され、 `identifier$g ~tokか, または `ArgumentNameKeyword$g 記号に合致する~keywordで与えられる。 これらの~keywordのいずれかが利用される場合、先頭の underscore による~escapeは不要である。 ◎ Operation arguments can take a slightly wider set of identifiers. In an operation declaration, the identifier of an argument is specified immediately after its type and is given by either an identifier token or by one of the keywords that match the ArgumentNameKeyword symbol. If one of these keywords is used, it need not be escaped with a leading underscore.

`return-type^i `operation-identifier^i(`argument-type^i `argument-identifier^mk, …);
-ArgumentNameKeyword

演算~引数に `identifier$g ~tokが利用された場合、その`識別子$はその~tokから先頭の `U+005F LOW LINE ("_")^char 文字( underscore )を取り除いた値になる。 代わりにいずれかの `ArgumentNameKeyword$g ~keyword~tokが利用された場合、演算~引数の`識別子$は単にその~tokになる。 ◎ If an identifier token is used, then the identifier of the operation argument is the value of that token with any leading U+005F LOW LINE ("_") character (underscore) removed. If instead one of the ArgumentNameKeyword keyword token is used, then the identifier of the operation argument is simply that token.

上に示されたどの~IDL構成子のどの`識別子$も `constructor^l, `toString^l, `toJSON^l になっては~MUST_NOT。 また、文字 `U+005F LOW LINE ("_")^char から始まっては~MUST_NOT。 これらは `予約済み識別子@ と呼ばれる。 ◎ The identifier of any of the abovementioned IDL constructs MUST NOT be “constructor”, “toString”, “toJSON”, or begin with a U+005F LOW LINE ("_") character. These are known as reserved identifiers.

後の節にて、一部の特定0の構成子に対しては,識別子の名前に更なる制約が課され得る。 ◎ Further restrictions on identifier names for particular constructs may be made in later sections.

所与の実装が~supportする `~IDL片$の集合に属する、どの[ `~ifc$, `辞書$, `列挙$, `呼戻~関数$, `~typedef$ ]の`識別子$も,他のそれと互いに同じになっては~MUST_NOT。 ◎ Within the set of IDL fragments that a given implementation supports, the identifier of every interface, dictionary, enumeration, callback function and typedef MUST NOT be the same as the identifier of any other interface, dictionary, enumeration, callback function or typedef.

`~IDL片$の中における`定義$への参照が、参照~先の定義の宣言より後に現れる必要はない。 参照は複数の`~IDL片$をまたがることもできる。 ◎ Within an IDL fragment, a reference to a definition need not appear after the declaration of the referenced definition. References can also be made across IDL fragments.

したがって,次の`~IDL片$は妥当である: ◎ Therefore, the following IDL fragment is valid:

interface B : A {
  void f(SequenceOfLongs x);
};

interface A {
};

typedef sequence<long> SequenceOfLongs;

`定義$/`~ifc~mb$に,`識別子$を与える例を、次の`~IDL片$に示す: ◎ The following IDL fragment demonstrates how identifiers are given to definitions and interface members.

// ~typedef識別子: `number^l
typedef double number;

// ~ifc識別子: `System^l
interface System {

  // 演算~識別子: `createObject^l
  // 演算~引数~識別子: `interface^l
  object createObject(DOMString _interface);

  // 演算~引数~識別子: `interface^l
  sequence<object> getObjects(DOMString interface);

  // 演算は識別子を持たない。取得子を宣言する。
  getter DOMString (DOMString keyName);
};

// ~ifc識別子: `TextField^l
interface TextField {

  // 属性~識別子: `const^l
  attribute boolean _const;

  // 属性~識別子: `value^l
  attribute DOMString? _value;
};

`TextField^T `~ifc$ の二番目の`属性$は( `value^l は~IDL文法の~keywordではないので) underscore で~escapeする必要はないが、属性の`識別子$を得る際には,依然として~escapeは外される。 ◎ Note that while the second attribute on the TextField interface need not have been escaped with an underscore (because “value” is not a keyword in the IDL grammar), it is still unescaped to obtain the attribute’s identifier.

3.2. ~ifc

`~IDL片$は~obj指向~systemの記述に利用される。 その種の~systemにおいては、~objは同一性( identity )を持つ実体であり,状態と挙動の~encapsulationである。 `~ifc@ とは、その~ifcを実装する~objが公開することになる,何らかの状態や挙動を宣言するための,`定義$( `Interface$g / `callback^sym `Interface$g いずれかに合致)である。 ◎ IDL fragments are used to describe object oriented systems. In such systems, objects are entities that have identity and which are encapsulations of state and behavior. An interface is a definition (matching Interface or "callback" Interface) that declares some state and behavior that an object implementing that interface will expose.

interface `identifier^i {
  `interface-members…^i
};

~ifcは、~ifc宣言の波括弧の合間に現れる,一連の `~ifc~mb@ — `定数$, `属性$, `演算$, その他の宣言 — が成す集合( `InterfaceMembers$g に合致)の仕様である。 属性は,その~ifcを実装する~objが公開することになる状態を記述し、演算は,~obj上で呼出せる挙動を記述する。 定数は,~system内の~objの利用者の便宜のために公開される,有名~定数~値を宣言する。 ◎ An interface is a specification of a set of interface members (matching InterfaceMembers), which are the constants, attributes, operations and other declarations that appear between the braces in the interface declaration. Attributes describe the state that an object implementing the interface will expose, and operations describe the behaviors that can be invoked on the object. Constants declare named constant values that are exposed as a convenience to users of objects in the system.

Web IDL の~ifcは,その~ifcを実装する~objがどのように挙動するかを記述する。 ~obj指向~言語のための言語束縛においては、個々の~IDL~ifcを実装する~objは,[ ~objの状態を検分したり改変する仕方,~ifcに記述された挙動を呼出す仕方 ]を提供することが期待されている。 ◎ Interfaces in Web IDL describe how objects that implement the interface behave. In bindings for object oriented languages, it is expected that an object that implements a particular IDL interface provides ways to inspect and modify the object's state and to invoke the behavior described by the interface.

~ifcは,別の~ifc(の~mb)を `継承-@ するようにも定義し得る。 ~ifcの識別子に文字 `U+003A COLON (":")^char と`識別子$が後続している場合、後者の識別子が,継承される~ifcを識別する。 ある~ifc %I を継承する~ifcを実装する~objは, %I も実装する。 ~objはしたがって, %I からの~ifc~mbに対応する~mbも持つことになる。 ◎ An interface can be defined to inherit from another interface. If the identifier of the interface is followed by a U+003A COLON (":") character and an identifier, then that identifier identifies the inherited interface. An object that implements an interface that inherits from another also implements that inherited interface. The object therefore will also have members that correspond to the interface members from the inherited interface.

interface `identifier^i : `identifier-of-inherited-interface^mk {
  `interface-members…^i
};

~mbが現れる順序は、多重定義の場合を除いて有意でない。 ◎ The order that members appear in has no significance except in the case of overloading.

~ifcは、継承される~ifcの~mbと同じ名前を持つ,~ifc~mbを指定してもよい。 派生~ifcを実装する~objは、派生~ifc上でそれらの~mbを公開することになる。 その~obj上で上書きされた~mbに~accessし得るかどうかは、言語束縛~特有になる。 ◎ Interfaces may specify an interface member that has the same name as one from an inherited interface. Objects that implement the derived interface will expose the member on the derived interface. It is language binding specific whether the overridden member can be accessed on the object.

次の2つの~ifcを考える ◎ Consider the following two interfaces.

interface A {
  void f();
  void g();
};

interface B : A {
  void f();
  void g(DOMString x);
};

~JS言語束縛においては、 `B^T の~instanceは,次の様な原型鎖を持つことになる: ◎ In the ECMAScript language binding, an instance of B will have a prototype chain that looks like the following:

[ `Object.prototype^v : `Object^t 原型~obj] ↑ [ `A.prototype^v : `A^T の~ifc原型~obj] ↑ [ `B.prototype^v : `B^T の~ifc原型~obj] ↑ [ `B^T の~instance]

~JSにおける `instanceOfB.f()^c の~callは、 `B^T 上で定義された f を呼出すことになる。 しかしながら, `A^T 上の f も、依然として `A.prototype.f.call(instanceOfB)^c の~callにより, `B^T を実装する~obj上で呼出せる。 ◎ Calling instanceOfB.f() in ECMAScript will invoke the f defined on B. However, the f from A can still be invoked on an object that implements B by calling A.prototype.f.call(instanceOfB).

所与の~ifc %A の `被継承~ifc@ とは、[ %A が直接的にまたは間接的に継承する,すべての~ifc ]からなる集合である。 %A が 他の~ifcを`継承-$しない場合、集合は空である。 他の場合、その集合には, %A が継承する~ifc %B と %B の`被継承~ifc$すべてが含まれる。 ◎ The inherited interfaces of a given interface A is the set of all interfaces that A inherits from, directly or indirectly. If A does not inherit from another interface, then the set is empty. Otherwise, the set includes the interface B that A inherits from and all of B’s inherited interfaces.

~ifcは、その継承階層が循環するように宣言されては~MUST_NOT。 すなわち、~ifc %A は自身を継承することも, %A を継承する別の~ifc %B を継承することもできない,等々。 ◎ An interface MUST NOT be declared such that its inheritance hierarchy has a cycle. That is, an interface A cannot inherit from itself, nor can it inherit from another interface B that inherits from A, and so on.

~ifcの一般的な多重~継承は~supportされず,~objは~ifcの任意の集合を実装することはできないことに注意。 ~objは、所与の[ 単独の~ifc %A ]を実装するように,すなわち %A の`被継承~ifc$すべてを実装するように,定義できる。 加えて、`~implements文$を利用すれば,[ ある~ifcを実装している~objが,常にある別の~ifcも実装する ]ように定義することもできる。 ◎ Note that general multiple inheritance of interfaces is not supported, and objects also cannot implement arbitrary sets of interfaces. Objects can be defined to implement a single given interface A, which means that it also implements all of A’s inherited interfaces. In addition, an implements statement can be used to define that objects implementing an interface will always also implement another interface.

各~ifc~mbの前には、`拡張属性$の~list( `ExtendedAttributeList$g に合致)を置くことができる — それらは、その~ifc~mbが,言語束縛において どう取扱われるかを制御する。 ◎ Each interface member can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how the interface member will be handled in language bindings.

interface `identifier^i {

  [`extended-attributes^mk]
  const `type^i `identifier^i = `value^i;

  [`extended-attributes^mk]
  attribute `type^i `identifier^i;

  [`extended-attributes^mk]
  `return-type^i `identifier^i(`arguments…^i);
};

`呼戻~ifc@ は,その定義の先頭に `callback^c ~keywordを利用する`~ifc$である。 呼戻~ifcは、 `idl-objects$sec で述べるように,`~platform~obj$ではなく,`利用者~obj$により実装され得るものである。 ◎ A callback interface is an interface that uses the callback keyword at the start of its definition. Callback interfaces are ones that can be implemented by user objects and not by platform objects, as described in section 3.9 below.

callback interface `identifier^i {
  `interface-members…^i
};

似た命名の`呼戻~関数$定義も見よ。 ◎ See also the similarly named callback function definition.

`呼戻~ifc$は非~呼戻~ifcを`継承-$しては~MUST_NOT。 非~呼戻~ifcは呼戻~ifcを`継承-$しては~MUST_NOT。 呼戻~ifcには`帰結~ifc$が存在しては~MUST_NOT。 ◎ Callback interfaces MUST NOT inherit from any non-callback interfaces, and non-callback interfaces MUST NOT inherit from any callback interfaces. Callback interfaces MUST NOT have any consequential interfaces.

`呼戻~ifc$上に[ `静的~属性$ / `静的~演算$ ]が定義されては~MUST_NOT。 ◎ Static attributes and static operations MUST NOT be defined on a callback interface.

仕様~策定者は、既存の API の要件の記述に不可欠な場合を除き,単独の`演算$のみを持つ`呼戻~ifc$を定義する~SHOULD_NOT。 代わりに,`呼戻~関数$が利用される~SHOULD。 ◎ Specification authors SHOULD NOT define callback interfaces that have only a single operation, unless required to describe the requirements of existing APIs. Instead, a callback function SHOULD be used.

`呼戻~ifc$である `EventListener^T の定義は、所与の~prop(この場合は `handleEvent^l )を伴う`利用者~obj$により その~ifcを実装することが,許容される必要があるものと見なされている、既存の API の例である。 新たな API, あるいは互換性の心配がない API のための`呼戻~関数$には、(~JS言語束縛においては) `Function^t ~objのみが許容されることになる。 ◎ The definition of EventListener as a callback interface is an example of an existing API that needs to allow user objects with a given property (in this case “handleEvent”) to be considered to implement the interface. For new APIs, and those for which there are no compatibility concerns, using a callback function will allow only a Function object (in the ECMAScript language binding).

上の警告は,将来に呼戻~ifcを拡張する際には、おそらく適用されるべきではないであろう。 それが単一~演算~呼戻~ifcから取り掛かる良い理由になると見られる。 ◎ Perhaps this warning shouldn't apply if you are planning to extend the callback interface in the future. That's probably a good reason to start off with a single operation callback interface.

編集者は,[ 所与の呼戻~ifcを実装している利用者~obj上で,演算が実装されていない場合 ]を~supportする必要があると考えている。 既存の呼戻~ifcを拡張する仕様は、おそらく,実装されていない演算の~callを避けることが求まれるであろう(代わりに何らかの既定の挙動を持たせて)。 従って,演算が実装されているかどうか意味する用語が定義されるべきであろう — ~JS言語束縛における,~propの有無の検査に対応することになるような。 ◎ I think we need to support operations not being implemented on a given user object implementing a callback interface. If specs extending an existing callback interface, we probably want to be able to avoid calling the operations that aren't implemented (and having some default behavior instead). So we should perhaps define a term that means whether the operation is implemented, which in the ECMAScript binding would correspond to checking for the property's existence.

関数~引数として “~propの集まり( property bag )” のような~JS~objをとる API を定義する仕様の策定者には、`呼戻~ifc$よりも`辞書~型$の利用を勧める。 ◎ Specification authors wanting to define APIs that take ECMAScript objects as “property bag” like function arguments are suggested to use dictionary types rather than callback interfaces.

例えば,次のものは: ◎ For example, instead of this:

callback interface Options {
  attribute DOMString? option1;
  attribute DOMString? option2;
  attribute long? option3;
};

interface A {
  void doTask(DOMString type, Options options);
};

次の様な利用を可能にするために: ◎ to be used like this:

var a = getA();  // `A^T の~instanceを取得する。

a.doTask("something", { option1: "banana", option3: 100 });

代わりに,次のように記す: ◎ instead write the following:

dictionary Options {
  DOMString? option1;
  DOMString? option2;
  long? option3;
};

interface A {
  void doTask(DOMString type, Options options);
};

~ifcに対する~IDLは、 `部分的~ifc定義@ ( `partial^sym `PartialInterface$g に合致)を利用して,複数の部分に分割できる。 部分的~ifc定義の`識別子$は、その~ifc定義の識別子と同じで~MUST。 それぞれの部分的~ifcに現れる,すべての~mbは、その~ifc自身の~mbであるものと見なされる。 ◎ The IDL for interfaces can be split into multiple parts by using partial interface definitions (matching "partial" PartialInterface). The identifier of a partial interface definition MUST be the same as the identifier of an interface definition. All of the members that appear on each of the partial interfaces are considered to be members of the interface itself.

interface `SomeInterface^mk {
  `interface-members…^i
};

partial interface `SomeInterface^mk {
  `interface-members…^i
};

部分的~ifc定義の目的は、~ifcの定義を 文書の複数の節, ときには複数の文書に分離できるようにして,仕様の編集を補助する所にある。 ◎ Partial interface definitions are intended for use as a specification editorial aide, allowing the definition of an interface to be separated over more than one section of the document, and sometimes multiple documents.

`~ifc$定義, およびその`部分的~ifc定義$が現れる順序は問題にされない。 ◎ The order of appearance of an interface definition and any of its partial interface definitions does not matter.

部分的~ifc定義においては、別の~ifcからの`継承-$は指定できない。 継承は元の`~ifc$定義に指定され~MUST。 ◎ A partial interface definition cannot specify that the interface inherits from another interface. Inheritance must be specified on the original interface definition.

多少の制限もあるが、`部分的~ifc定義$にも,`拡張属性$を指定できる。 次の拡張属性は,部分的~ifc定義に指定されては~MUST_NOT: `Constructor$x, `ImplicitThis$x, `LegacyArrayClass$x `NamedConstructor$x, `NoInterfaceObject$x 。 ◎ Extended attributes can be specified on partial interface definitions, with some limitations. The following extended attributes MUST NOT be specified on partial interface definitions: [Constructor], [ImplicitThis], [LegacyArrayClass], [NamedConstructor], [NoInterfaceObject].

`Exposed$x, `Global$x, `OverrideBuiltins$x, `PrimaryGlobal$x, `SecureContext$x, `Unforgeable$x を除き,上に挙げたものが この文書に定義される中で`~ifc$に適用し得る`拡張属性$のすべてである。 ◎ The above list of extended attributes is all of those defined in this document that are applicable to interfaces except for [Exposed], [Global], [OverrideBuiltins], [PrimaryGlobal], [SecureContext] and [Unforgeable].

`部分的~ifc定義$に指定される `拡張属性$は `~ifc$自身に現れるものと見なされる。 ◎ Any extended attribute specified on a partial interface definition is considered to appear on the interface itself.

関連の言語束縛が,~ifcと[ 言語の構成子 ]との間の対応付けを決定する。 ◎ The relevant language binding determines how interfaces correspond to constructs in the language.

~ifcには、次の拡張属性を適用し得る: `Constructor$x, `Exposed$x, `Global$x, `ImplicitThis$x, `LegacyArrayClass$x, `NamedConstructor$x, `NoInterfaceObject$x, `OverrideBuiltins$x, `PrimaryGlobal$x, `SecureContext$x, `Unforgeable$x 。 ◎ The following extended attributes are applicable to interfaces: [Constructor], [Exposed], [Global], [ImplicitThis], [LegacyArrayClass], [NamedConstructor], [NoInterfaceObject], [OverrideBuiltins], [PrimaryGlobal], [SecureContext], [Unforgeable].

--CallbackOrInterface -CallbackRestOrInterface -Interface -Partial -PartialDefinition -PartialInterface -InterfaceMembers -InterfaceMember -Inheritance

次の`~IDL片$に、2つの相互に参照しあう`~ifc$ — `Human^T と `Dog^T — の定義~例を示す。 いずれも `Animal^T を継承するので、2つの~ifcいずれかを実装する~objは, `name^M 属性も持つことになる。 ◎ The following IDL fragment demonstrates the definition of two mutually referential interfaces. Both Human and Dog inherit from Animal. Objects that implement either of those two interfaces will thus have a name attribute.

interface Animal {
  attribute DOMString name;
};

interface Human : Animal {
  attribute Dog? pet;
};

interface Dog : Animal {
  attribute Human? owner;
};

次の`~IDL片$は DOM `~ifc$の一部を単純化した~versionを定義する。 うち1個は`呼戻~ifc$である。 ◎ The following IDL fragment defines simplified versions of a few DOM interfaces, one of which is a callback interface.

interface Node {
  readonly attribute DOMString nodeName;
  readonly attribute Node? parentNode;
  Node appendChild(Node newChild);
  void addEventListener(DOMString type, EventListener listener);
};

callback interface EventListener {
  void handleEvent(Event event);
};

`EventListener^T ~ifcは呼戻~注釈付きの~ifcなので,`利用者~obj$により実装し得る: ◎ Since the EventListener interface is annotated callback interface, user objects can implement it:

var node = getNode();  // `Node^T の~instanceを得る。

var listener = {
  handleEvent: function(event) {
    ...
  }
};
node.addEventListener("click", listener);            // これは機能する。

node.addEventListener("click", function() { ... });  // これと同様に。

しかしながら,利用者~objは `Node^T を実装することはできない: ◎ It is not possible for a user object to implement Node, however:

var node = getNode();  // 

var newNode = {
  nodeName: "span",
  parentNode: null,
  appendChild: function(newchild) {
    ...
  },
  addEventListener: function(type, listener) {
    ...
  }
};
node.appendChild(newNode);  // `TypeError^T 例外が投出されることになる。

3.2.1. 定数

`定数@ は、定数~値を名前に束縛するために利用される,宣言( `Const$g に合致)である。 定数は`~ifc$に現れ得る。 ◎ A constant is a declaration (matching Const) used to bind a constant value to a name. Constants can appear on interfaces.

過去においては,定数は、主に,有名~整数~codeを列挙する~styleで定義されていた。 Web ~platformは、文字列の利用を支持し,この設計patternから離れつつある。 定数の定義を要する仕様~策定者は、`論ML^。 ◎ Constants have in the past primarily been used to define named integer codes in the style of an enumeration. The Web platform is moving away from this design pattern in favor of the use of strings. Specification authors who wish to define constants are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

const `type^i `identifier^i = `value^i;

`定数$の`識別子$は[ 同じ~ifc上で定義される別の`~ifc~mb$ ]の識別子と同じになっては~MUST_NOT。 また、識別子が[ `length^l / `name^l / `prototype^l ]になっては~MUST_NOT。 ◎ The identifier of a constant MUST NOT be the same as the identifier of another interface member defined on the same interface. The identifier also MUST NOT be “length”, “name” or “prototype”.

これらの名前は、すべての `Function^t ~objに存在する~propの名前である。 ◎ These three names are the names of properties that exist on all Function objects.

定数の型( `ConstType$g に合致)は、[ `~primitive型$または`~nullable$~primitive型 ]で~MUST。 `識別子$が利用される場合、その識別子は[ ~primitive型または~nullable~primitive型 ]の`~typedef$を参照し~MUST。 ◎ The type of a constant (matching ConstType) MUST NOT be any type other than a primitive type or a nullable primitive type. If an identifier is used, it MUST reference a typedef whose type is a primitive type or a nullable primitive type.

定数~宣言の `ConstValue$g 部は定数の値を与え、次のいずれかの~tokをとり得る:

  • 2つの真偽~literal( `true^c と `false^c )
  • `null^c
  • `integer$g
  • `float$g
  • 3つの特別な浮動小数点~定数~値( `-Infinity^c, `Infinity^c, `NaN^c )

【 この訳では、これらの~tokを総称して, `定数~tok@ と呼ぶことにする。 】

◎ The ConstValue part of a constant declaration gives the value of the constant, which can be one of the two boolean literal tokens (true and false), the null token, an integer token, a float token, or one of the three special floating point constant values (-Infinity, Infinity and NaN).

文字列や空~連列に加え,これらの値も[ 辞書~mbの`辞書既定値^や, 随意~引数の`既定~値$ ]を指定するために利用できる。 文字列や空~連列 `[]^c は、`定数$の値には利用できないことに注意。 ◎ These values – in addition to strings and the empty sequence – can also be used to specify the default value of a dictionary member or of an optional argument. Note that strings and the empty sequence [] cannot be used as the value of a constant.

真偽~literal~tokの値は、それぞれ, ~IDL `boolean$T 値[ `true^V, `false^V ]になる。 ◎ The value of the boolean literal tokens true and false are the IDL boolean values true and false.

`integer$g ~tokの値は、次に従って決定される整数~値になる: ◎ The value of an integer token is an integer whose value is determined as follows:

  1. %S := `integer$g ~tokに合致する文字~並び ◎ Let S be the sequence of characters matched by the integer token.
  2. %sign := [ %S の先頭が `U+002D HYPHEN-MINUS ("-")^char ならば −1 / ~ELSE_ 1 ] ◎ Let sign be −1 if S begins with U+002D HYPHEN-MINUS ("-"), and 1 otherwise.
  3. %base := %S から先頭の `U+002D HYPHEN-MINUS ("-")^char は(もしあれば)除いた残りの部分の,頭部の文字~並びに基づく基数: ◎ Let base be the base of the number based on the characters that follow the optional leading U+002D HYPHEN-MINUS ("-") character:

    `0X^l ( `U+0030 DIGIT ZERO ("0")^char, `U+0058 LATIN CAPITAL LETTER X ("X")^char )
    `0x^l ( `U+0030 DIGIT ZERO ("0")^char, `U+0078 LATIN SMALL LETTER X ("x")^char )
    基数は 16 ◎ The base is 16.
    `U+0030 DIGIT ZERO ("0")^char
    基数は 8 ◎ The base is 8.
    その他
    基数は 10 ◎ The base is 10.
  4. %number := %S から頭部の [ `U+002D HYPHEN-MINUS ("-")^char / 基数を指示する文字~並び ]を(もしあれば)除いた残りの文字すべてを,指定された基数 %base に基づいて整数に解釈した結果 ◎ Let number be the result of interpreting all remaining characters following the optional leading U+002D HYPHEN-MINUS ("-") character and any characters indicating the base as an integer specified in base base.
  5. ~RET %sign × %number ◎ Return sign × number.

`integer$g ~tokの型は、それを値に利用している [ 定数/辞書~mb/随意~引数 ] の型と同じである。 `integer$g ~tokの値は、 `idl-types$sec で与えられる,その型の値として妥当な範囲に入ら~MUST。 ◎ The type of an integer token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the integer token MUST NOT lie outside the valid range of values for its type, as given in section 3.10 below.

`float$g ~tokの値は、それを値に利用している [ 定数/辞書~mb/随意~引数 ] の型に依存して,単精度, 倍精度 いずれかの IEEE 754 浮動小数点数になり、次に従って決定される: ◎ The value of a float token is either an IEEE 754 single-precision floating point number or an IEEE 754 double-precision floating point number, depending on the type of the constant, dictionary member or optional argument it is being used as the value for, determined as follows:

  1. %S := `float$g ~tokに合致する文字~並び ◎ Let S be the sequence of characters matched by the float token.
  2. %value := %S を~JS `NumericLiteral^ ( `ECMA-262$r 11.8.3 節)として構文解析して得られる Mathematical Value ◎ Let value be the Mathematical Value that would be obtained if S were parsed as an ECMAScript NumericLiteral ([ECMA-262], section 11.8.3).
  3. ~IF `float$g ~tokが `float$T または `unrestricted float$T の値として利用されている ~THEN ~RET %value に最も近い IEEE 754 単精度 浮動小数点数 `IEEE-754$r ◎ If the float token is being used as the value for a float or unrestricted float, then the value of the float token is the IEEE 754 single-precision floating point number closest to result. Otherwise, the float token is being used as the value for a double or unrestricted double, and the value of the float token is the IEEE 754 double-precision floating point number closest to result. [IEEE-754]
  4. ~ELSE (すなわち `float$g ~tokが `double$T または `unrestricted double$T の値として利用されている) ~THEN ~RET %value に最も近い IEEE 754 倍精度 浮動小数点数 ◎ ↑

`Infinity^c, `-Infinity^c, `NaN^c のいずれかとして指定された定数~値は、それを値に利用している [ 定数/辞書~mb/随意~引数 ] の型に依存して,単精度, 倍精度 いずれかの IEEE 754 浮動小数点数になり、次に従って決定される: ◎ The value of a constant value specified as Infinity, -Infinity or NaN is either an IEEE 754 single-precision floating point number or an IEEE 754 double-precision floating point number, depending on the type of the constant, dictionary member or optional argument is is being used as the value for:

`unrestricted float$T 型の定数~値 `Infinity^c ◎ Type unrestricted float, constant value Infinity
値は IEEE 754 単精度,正の無限~値 ◎ The value is the IEEE 754 single-precision positive infinity value.
`unrestricted double$T 型の定数~値 `Infinity^c ◎ Type unrestricted double, constant value Infinity
値は IEEE 754 倍精度,正の無限~値 ◎ The value is the IEEE 754 double-precision positive infinity value.
`unrestricted float$T 型の定数~値 `-Infinity^c ◎ Type unrestricted float, constant value -Infinity
値は IEEE 754 単精度,負の無限~値 ◎ The value is the IEEE 754 single-precision negative infinity value.
`unrestricted double$T 型の定数~値 `-Infinity^c ◎ Type unrestricted double, constant value -Infinity
値は IEEE 754 倍精度,負の無限~値 ◎ The value is the IEEE 754 double-precision negative infinity value.
`unrestricted float$T 型の定数~値 `NaN^c ◎ Type unrestricted float, constant value NaN
値は~bit~pattern 0x7fc00000 の, IEEE 754 単精度 NaN ◎ The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000.
`unrestricted double$T 型の定数~値 `NaN^c ◎ Type unrestricted double, constant value NaN
値は~bit~pattern 0x7ff8000000000000 の, IEEE 754 倍精度 NaN ◎ The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000.

`float$g ~tokの型は、それを値に利用している [ 定数/辞書~mb/随意~引数 ] の型と同じになる。 `float$g ~tokの値は、 `idl-types$sec で与えられるように,その型の値として妥当な範囲の外にあっては~MUST_NOT。 また、[ `Infinity^c, `-Infinity^c, `NaN^c ]が[ `float$T や `double$T ]の値として利用されては~MUST_NOT。 ◎ The type of a float token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the float token MUST NOT lie outside the valid range of values for its type, as given in section 3.10 below. Also, Infinity, -Infinity and NaN MUST NOT be used as the value of a float or double.

`null^c ~tokの値は、`~nullable型$に属する特別な `null^V 値である。 `null^c ~tokの型は、それを値に利用している [ 定数/辞書~mb/随意~引数 ] の型と同じになる。 ◎ The value of the null token is the special null value that is a member of the nullable types. The type of the null token is the same as the type of the constant, dictionary member or optional argument it is being used as the value of.

%VT を定数にあてがわれる値の型, %DT を[ 定数/辞書~mb/随意~引数 ]自身の型とするとき、これらの型は互換,すなわち %DT と %VT が一致するか, または %DT はその`内縁~型$が %VT であるような`~nullable型$でなければ~MUST。 ◎ If VT is the type of the value assigned to a constant, and DT is the type of the constant, dictionary member or optional argument itself, then these types MUST be compatible, which is the case if DT and VT are identical, or DT is a nullable type whose inner type is VT.

`定数$は それが現れる`~ifc$の個々の~instanceには結付けられない。 `定数$が~instanceにも公開されるかどうかは 言語束縛~特有になる。 ◎ Constants are not associated with particular instances of the interface on which they appear. It is language binding specific whether constants are exposed on instances.

~JS言語束縛では,しかしながら、`定数$が宣言されている~IDL`~ifc$を実装する~objを通して,`定数$への~accessが許容される。 例えば次の~IDLでは: ◎ The ECMAScript language binding does however allow constants to be accessed through objects implementing the IDL interfaces on which the constants are declared. For example, with the following IDL:

interface A {
  const short rambaldi = 47;
};

~JSにおいては、この定数~値は,[ `A.rambaldi^c および (`A^T の~instance)`.rambaldi^c ]として~accessできる。 ◎ the constant value can be accessed in ECMAScript either as A.rambaldi or instanceOfA.rambaldi.

定数には、次の拡張属性を適用し得る: `Exposed$x, `SecureContext$x ◎ The following extended attributes are applicable to constants: [Exposed], [SecureContext].

-Const -ConstValue -BooleanLiteral -FloatLiteral -ConstType

次の`~IDL片$に、上の型の`定数$を定義する例を示す。 ◎ The following IDL fragment demonstrates how constants of the above types can be defined.

interface Util {
  const boolean DEBUG = false;
  const octet LF = 10;
  const unsigned long BIT_MASK = 0x0000fc00;
  const double AVOGADRO = 6.022e23;
};

3.2.2. 属性

`属性@ ( `inherit^sym `ReadOnly$g `AttributeRest$g / `static^sym `ReadOnly$g `AttributeRest$g / `stringifier^sym `ReadOnly$g `AttributeRest$g / `ReadOnly$g `AttributeRest$g いずれかに合致)は、[ `~ifc$を実装している~objが,[ 所与の[ 型, `識別子$ ]により,値の取得0や(一部の場合は)変更を行える ]~data~fieldを持つことになる ]ことを宣言するために利用される, `~ifc~mb$である。 属性は次の2種類に分けられる: ◎ An attribute is an interface member (matching "inherit" ReadOnly AttributeRest, "static" ReadOnly AttributeRest, "stringifier" ReadOnly AttributeRest, or ReadOnly AttributeRest) that is used to declare data fields with a given type and identifier whose value can be retrieved and (in some cases) changed. There are two kinds of attributes:

  1. `正則~属性$は、`~ifc$を実装している~objが,所与の`識別子$を伴う~data~field~mbを持つことになることを宣言するために利用される。 ◎ regular attributes, which are those used to declare that objects implementing the interface will have a data field member with the given identifier

    attribute `type^i `identifier^i;
    
  2. `静的~属性$は、その~ifcを実装している個々の~objには結付けられない属性を宣言するために利用される。 ◎ static attributes, which are used to declare attributes that are not associated with a particular object implementing the interface

    static attribute `type^i `identifier^i;
    

`static^c ~keywordを伴わない属性は `正則~属性@ を宣言する。 そうでなければ,`静的~属性$を宣言する。 ◎ If an attribute has no static keyword, then it declares a regular attribute. Otherwise, it declares a static attribute.

`属性$の`識別子$は[ 同じ`~ifc$上に定義される別の`~ifc~mb$の識別子 ]と同じになっては~MUST_NOT。 静的~属性の識別子が `prototype^l になっては~MUST_NOT。 ◎ The identifier of an attribute MUST NOT be the same as the identifier of another interface member defined on the same interface. The identifier of a static attribute MUST NOT be “prototype”.

属性の型は、 `attribute^c ~keywordの後に現れる 型( `Type$g に合致)で与えられる。 `Type$g が[ `識別子$, または `?^c が後続する識別子 ]である場合、その識別子は[ ~ifc, `列挙$, `呼戻~関数$, `~typedef$ ]のいずれかとして識別され~MUST。 ◎ The type of the attribute is given by the type (matching Type) that appears after the attribute keyword. If the Type is an identifier or an identifier followed by ?, then the identifier MUST identify an interface, enumeration, callback function or typedef.

属性の型は、~typedefの解決-後に,次に挙げる型, あるいはその`~nullable型$になっては~MUST_NOT。 ◎ The type of the attribute, after resolving typedefs, MUST NOT be a nullable or non-nullable version of any of the following types:

  • `連列~型$ ◎ a sequence type
  • `辞書$ ◎ a dictionary
  • その`平坦化~mb型$に[ [ ~nullable/非~nullable ]の連列~型, または辞書 ]を含んでいるような,`共用体~型$ 【 平坦化~mb型は~nullableを含み得ないので,この “~nullable” の記述は不要では? 】 ◎ a union type that has a nullable or non-nullable sequence type or dictionary as one of its flattened member types

`attribute^c ~keywordの前に `readonly^c ~keywordが利用されている場合、属性は `読専@( readonly, 読み取り専用) になる。 [ 読専の属性が定義されている~ifc ]を実装する~objにおいては、その属性に対する代入は許容されないことになる。 代入が、単に言語において許容されないのか, 無視されるのか, あるいは例外が投出されるのか,については、言語束縛~特有になる。 ◎ The attribute is read only if the readonly keyword is used before the attribute keyword. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown.

readonly attribute `type^i `identifier^i;

`読専$でない`正則~属性$は、先祖の~ifcからその `取得子を継承-@ するように宣言できる。 これにより、先祖~ifcの読専の属性を,派生~ifc上で~writableにできる。 属性は、その宣言が `inherit^c を伴うとき,`取得子を継承-$するものとされる。 その属性が取得子を継承する読専の属性は、[ 同じ識別子の属性が定義されている,先祖の~ifc ]のうち,最も末端の~ifcに属する属性である。 取得子を[ 継承する側, される側 ]の属性の型は同じで~MUST。 また、 `inherit^c が[ `読専$の属性/`静的~属性$ ]に現れては~MUST_NOT。 ◎ A regular attribute that is not read only can be declared to inherit its getter from an ancestor interface. This can be used to make a read only attribute in an ancestor interface be writable on a derived interface. An attribute inherits its getter if its declaration includes inherit in the declaration. The read only attribute from which the attribute inherits its getter is the attribute with the same identifier on the closest ancestor interface of the one on which the inheriting attribute is defined. The attribute whose getter is being inherited MUST be of the same type as the inheriting attribute, and inherit MUST NOT appear on a read only attribute or a static attribute.

interface `Ancestor^i {
  readonly attribute `TheType^i `theIdentifier^i;
};

interface `Derived^i : `Ancestor^i {
  inherit attribute `TheType^i `theIdentifier^i;
};

`正則~属性$の宣言に `stringifier^c ~keywordが利用されている場合、その~ifcを実装している~objが文字列化されるときに,その属性の値になることを指示する。 詳細は `idl-stringifiers$sec に。 ◎ When the stringifier keyword is used in a regular attribute declaration, it indicates that objects implementing the interface will be stringified to the value of the attribute. See section 3.2.4.2 below for details.

stringifier attribute DOMString `identifier^i;

実装が `利用者~obj$上の`属性$の値の取得-または設定-を試みたときに(例えば 呼戻~objが実装に供されているとき),その試みによる~~結果,例外が投出される場合、他から指定されない限り,その例外は[ 実装からその属性への~accessを生じさせた,利用者~code ]まで伝播することになる。 同様に、属性の取得-により返される値を~IDL型の値に変換できない場合、それにより生じた例外も[ 実装からその属性の値の取得を試みさせた,利用者~code ]まで伝播することになる。 ◎ If an implementation attempts to get or set the value of an attribute on a user object (for example, when a callback object has been supplied to the implementation), and that attempt results in an exception being thrown, then, unless otherwise specified, that exception will be propagated to the user code that caused the implementation to access the attribute. Similarly, if a value returned from getting the attribute cannot be converted to an IDL type, then any exception resulting from this will also be propagated to the user code that resulted in the implementation attempting to get the value of the attribute.

[ 正則/静的 ]属性には、次の`拡張属性$を適用し得る: `Clamp$x, `EnforceRange$x, `Exposed$x, `SameObject$x, `SecureContext$x, `TreatNullAs$x, 。 ◎ The following extended attributes are applicable to regular and static attributes: [Clamp], [EnforceRange], [Exposed], [SameObject], [SecureContext], [TreatNullAs].

次の`拡張属性$は、正則~属性のみに適用し得る: `LenientSetter$x, `LenientThis$x, `PutForwards$x, `Replaceable$x, `Unforgeable$x ◎ The following extended attributes are applicable only to regular attributes: [LenientSetter], [LenientThis], [PutForwards], [Replaceable], [Unforgeable].

ReadOnlyMember ReadOnlyMemberRest ReadWriteAttribute AttributeRest AttributeName AttributeNameKeyword Inherit ReadOnly

次の`~IDL片$に,`~ifc$上にて`属性$を宣言する例を示す: ◎ The following IDL fragment demonstrates how attributes can be declared on an interface:

interface Animal {

  // 単純な,任意の文字列に設定され得る属性。
  readonly attribute DOMString name;

  // 値を代入できる属性。
  attribute unsigned short age;
};

interface Person : Animal {
  
  // 取得子の挙動を `Animal^T から継承する属性。
  // `Person^T の記述の中で指定する必要はない。
  inherit attribute DOMString name;
};

3.2.3. 演算

`演算@ ( `static^sym `OperationRest$g / `stringifier^sym `OperationRest$g / `serializer^sym `OperationRest$g / `ReturnType$g `OperationRest$g / `SpecialOperation$g いずれかに合致)は、その~ifcを実装している~obj上で呼出せる挙動を定義する, `~ifc~mb$である。 演算には次の3つの種類がある: ◎ An operation is an interface member (matching "static" OperationRest, "stringifier" OperationRest, "serializer" OperationRest, ReturnType OperationRest or SpecialOperation) that defines a behavior that can be invoked on objects implementing the interface. There are three kinds of operation:

  1. `正則~演算$: その`~ifc$を実装している~objが、所与の`識別子$を伴う~methを持つことになることを宣言するために利用される。 ◎ regular operations, which are those used to declare that objects implementing the interface will have a method with the given identifier

    `return-type^i `identifier^i(`arguments…^i);
    
  2. `特殊~演算$: ~objの~indexingや文字列化など、その~ifcを実装している~obj上の特殊な挙動を宣言するために利用される。 ◎ special operations, which are used to declare special behavior on objects implementing the interface, such as object indexing and stringification

    `special-keywords…^i `return-type^i `identifier^i(`arguments…^i);
    `special-keywords…^i `return-type^i (`arguments…^i);
    
  3. `静的~演算$: その~ifcを実装している個々の~objには結付けられない演算を宣言するために利用される。 ◎ static operations, which are used to declare operations that are not associated with a particular object implementing the interface

    static `return-type^i `identifier^i(`arguments…^i);
    

識別子を持ち, かつ `static^sym ~keywordがない演算は、 `正則~演算@ を宣言する。 1個~以上の`特殊~keyword$(すなわち,[ `Special$g に合致する~keyword, または `stringifier^c ~keyword ])が宣言に利用されている演算は,`特殊~演算$を宣言する。 演算を,正則~演算と特殊~演算を兼ねるように宣言することもできる。 特殊~演算についての詳細は `idl-special-operations$sec に。 ◎ If an operation has an identifier but no static keyword, then it declares a regular operation. If the operation has one or more special keywords used in its declaration (that is, any keyword matching Special, or the stringifier keyword), then it declares a special operation. A single operation can declare both a regular operation and a special operation; see section 3.2.4 below for details on special operations.

識別子を持たない演算は、いずれかの特殊~keywordを利用して,`特殊~演算$として宣言され~MUST。 ◎ If an operation has no identifier, then it MUST be declared to be a special operation using one of the special keywords.

`正則~演算$/`静的~演算$の識別子は、同じ`~ifc$上に定義される`定数$や`属性$の識別子と同じになっては~MUST_NOT。 静的~演算の識別子が `prototype^l になっては~MUST_NOT。 ◎ The identifier of a regular operation or static operation MUST NOT be the same as the identifier of a constant or attribute defined on the same interface. The identifier of a static operation MUST NOT be “prototype”.

しかしながら、識別子をその~ifc上の別の演算と同じにすることはできる。 演算の多重定義は、これにより指定される。 ◎ The identifier can be the same as that of another operation on the interface, however. This is how operation overloading is specified.

`静的~演算$の`識別子$は、同じ`~ifc$上に定義される`正則~演算$の識別子と同じになっては~MUST_NOT。 ◎ The identifier of a static operation also MUST NOT be the same as the identifier of a regular operation defined on the same interface.

演算の `返値型@ ( `ReturnType$g に合致)は、[ 随意の[ 演算の`識別子$ ]]の前に現れる型により 与えられる。 返値型 `void@T は,演算が値を返さないことを指示する。 返値型が `?^c 付きの`識別子$である場合、その識別子は[ ~ifc , 辞書 , `列挙$ , `呼戻~関数$ , `~typedef$ ]のいずれかに識別され~MUST。 ◎ The return type of the operation is given by the type (matching ReturnType) that appears before the operation’s optional identifier. A return type of void indicates that the operation returns no value. If the return type is an identifier followed by ?, then the identifier MUST identify an interface, dictionary, enumeration, callback function or typedef.

演算の引数( `ArgumentList$g に合致)は、宣言の中の丸括弧の合間にて与えられる。 それぞれの引数は、型( `Type$g に合致)の後に `識別子$( `ArgumentName$g に合致)を続けて指定される。 ◎ An operation’s arguments (matching ArgumentList) are given between the parentheses in the declaration. Each individual argument is specified as a type (matching Type) followed by an identifier (matching ArgumentName).

表現力のため、演算~引数の識別子には, `ArgumentNameKeyword$g 記号に合致する~keywordも,~escapeを要することなく 指定できる。 ◎ For expressiveness, the identifier of an operation argument can also be specified as one of the keywords matching the ArgumentNameKeyword symbol without needing to escape it.

演算~引数の `Type$g が `?^c 付きの`識別子$である場合、その識別子は[ ~ifc , `列挙$ , `呼戻~関数$ , `~typedef$ ]のいずれかに識別され~MUST。 演算~引数の型が `?^c 付きでない`識別子$である場合、その識別子は,それらのいずれかの定義か, または `辞書$に識別され~MUST。 ◎ If the Type of an operation argument is an identifier followed by ?, then the identifier MUST identify an interface, enumeration, callback function or typedef. If the operation argument type is an identifier not followed by ?, then the identifier MUST identify any one of those definitions or a dictionary.

`return-type^i `identifier^i(`type^i `identifier^i, `type^i `identifier^i, …);

各~引数の識別子は、同じ演算~宣言~内の他の引数の識別子と同じになっては~MUST_NOT。 ◎ The identifier of each argument MUST NOT be the same as the identifier of another argument in the same operation declaration.

各~引数の前には、`拡張属性$の~list( `ExtendedAttributeList$g に合致)を置くことができる — それらは、その引数として渡された値が,言語束縛において どう取扱われるかを制御する。 ◎ Each argument can be preceded by a list of extended attributes (matching ExtendedAttributeList), which can control how a value passed as the argument will be handled in language bindings.

`return-type^i `identifier^i([`extended-attributes^mk] `type^i `identifier^i, [`extended-attributes^mk] `type^i `identifier^i, …);

次の`~IDL片$は `~ifc$上に`正則~演算$を宣言する: ◎ The following IDL fragment demonstrates how regular operations can be declared on an interface:

interface Dimensions {
  attribute unsigned long width;
  attribute unsigned long height;
};

interface Button {

  // 引数をとらず, `boolean^T を返す演算
  boolean isMouseOver();

  // 多重定義された演算。
  void setDimensions(Dimensions size);
  void setDimensions(unsigned long width, unsigned long height);
};

演算の 最後の引数 の引数~型の直後に `...^c ~tokが利用されている場合、その演算は `可変個の引数をとる@ もの( variadic )と見なされる。 【 その最後の引数を `可変個~引数@ もしくは 末尾~引数 と記すことにする。 】 そのように宣言された演算は:

  • その末尾~引数の後に任意~個数の引数を伴って呼出せることを指示し、それらの余分な暗黙の形式的~引数の型は,末尾~引数と同じ型と見なされる。
  • 呼出すときには、末尾~引数を省略することもできる。
  • 末尾~引数~以外の引数が `...^c ~tokを伴って宣言されては~MUST_NOT。
◎ An operation is considered to be variadic if the final argument uses the ... token just after the argument type. Declaring an operation to be variadic indicates that the operation can be invoked with any number of arguments after that final argument. Those extra implied formal arguments are of the same type as the final explicit argument in the operation declaration. The final argument can also be omitted when invoking the operation. An argument MUST NOT be declared with the ... token unless it is the final argument in the operation’s argument list.
`return-type^i `identifier^i(`type^i... `identifier^i);
`return-type^i `identifier^i(`type^i `identifier^i, `type^i... `identifier^i);

`引数~listを引数にとる$`拡張属性$(この仕様で定義される `Constructor$x と `NamedConstructor$x ), および `呼戻~関数$についても、その引数~listに `...^c ~tokが利用されているならば,`可変個の引数をとる$ものと見なされる。 【 以下の記述における “演算†” には,これらの(構築子を与える)拡張属性や呼戻も含まれていると思われる。 】 ◎ Extended attributes that take an argument list ([Constructor] and [NamedConstructor], of those defined in this specification) and callback functions are also considered to be variadic when the ... token is used in their argument lists.

次の`~IDL片$は,可変個の引数をとる演算を2つ持つ~ifcを定義する: ◎ The following IDL fragment defines an interface that has two variadic operations:

interface IntegerSet {
  readonly attribute unsigned long cardinality;

  void union(long... ints);
  void intersection(long... ints);
};

~JS言語束縛においては、可変個の引数をとる演算は,後続の引数を受容し得る関数により実装される: ◎ In the ECMAScript binding, variadic operations are implemented by functions that can accept the subsequent arguments:

var s = getIntegerSet();  // `IntegerSet^T の~instanceを得る。

s.union();                // `ints^l に対応する引数を~~省略。
s.union(1, 4, 7);         // `ints^l に対応する3個の引数を渡す。

可変個の引数をとる関数を~supportしない言語のための言語束縛においては、その種の演算には,整数の 配列または~list を明示的に渡すように指定することになるであろう。 ◎ A binding for a language that does not support variadic functions might specify that an explicit array or list of integers be passed to such an operation.

`optional^c ~keywordを伴って宣言された引数は `随意~引数@ であるものと見なされる。 `可変個の引数をとる$演算†の`末尾~引数$も随意~引数と見なされる。 随意として宣言された引数は,演算†を呼出す時にその値を省略し得ることを指示する。 `末尾~引数$が,明示的に随意として宣言されては~MUST_NOT。 ◎ An argument is considered to be an optional argument if it is declared with the optional keyword. The final argument of a variadic operation is also considered to be an optional argument. Declaring an argument to be optional indicates that the argument value can be omitted when the operation is invoked. The final argument in an operation MUST NOT explicitly be declared to be optional if the operation is variadic.

`return-type^i `identifier^i(`type^i `identifier^i, optional `type^i `identifier^i);

随意~引数には `既定~値@ を指定できる。 引数の識別子に `U+003D EQUALS SIGN ("=")^char と 値( `DefaultValue$g に合致)が後続している場合、その値がその随意~引数の `既定~値$ を与える。 ただし、`可変個の引数をとる$演算†の`末尾~引数$には、既定~値が指定されては~MUST_NOT。 既定~値は、対応する引数が省略されて演算†が~callされたときに,その引数がとる値と見なされる。 ◎ Optional arguments can also have a default value specified. If the argument’s identifier is followed by a U+003D EQUALS SIGN ("=") and a value (matching DefaultValue), then that gives the optional argument its default value. The implicitly optional final argument of a variadic operation MUST NOT have a default value specified. The default value is the value to be assumed when the operation is called with the corresponding argument omitted.

`return-type^i `identifier^i(`type^i `identifier^i, optional `type^i `identifier^i = `value^i);

`boolean$T 型の引数には、既定~値として `true^V を利用しないことを強く勧める。 さもなければ、 `undefined^v に既定の変換(すなわち, `false^V )が利用されると期待する作者たちを惑わすことになるので。 ◎ It is strongly suggested not to use default value of true for boolean-typed arguments, as this can be confusing for authors who might otherwise expect the default conversion of undefined to be used (i.e., false).

次を満たす引数は、随意として指定され~MUST。

  • 引数の型は[ `辞書~型$である, または[ `共用体~型$であって,ある`辞書~型$を`平坦化~mb型$に含んでいる ], かつ
  • その辞書~型 %D と %D の先祖には,必須の~mbはない, かつ
  • 引数は最後の引数である, または 引数に後続するどの引数も`随意~引数$である。

そのような引数は、他から指定されない限り,常に[ 各~mbが`辞書既定値^にされた,空の辞書 ]を値にとるものと見なされる。

◎ If the type of an argument is a dictionary type or a union type that has a dictionary type as one of its flattened member types, and that dictionary type and its ancestors have no required members, and the argument is either the final argument or is followed only by optional arguments, then the argument MUST be specified as optional. Such arguments are always considered to have a default value of an empty dictionary, unless otherwise specified.

これは、作者が辞書の既定~値のみの利用を望むときでも,空の辞書~値を渡さずに済むような API の設計を促すためである。 ◎ This is to encourage API designs that do not require authors to pass an empty dictionary value when they wish only to use the dictionary’s default values.

辞書~型は明示的な既定~値を指定し得ないので、上の “他から指定されない限り” の条件は,`平坦化~mb型$に辞書~型が含まれているような`共用体~型$に対してのみ可能になる。 ◎ Dictionary types cannot have a default value specified explicitly, so the “unless otherwise specified” clause above can only be invoked for a union type that has a dictionary type as one of its flattened member types.

`既定~値$に`定数~tok$が利用された場合、`定数$に対するときと同じ仕方で解釈される。 ◎ When a boolean literal token (true or false), the null token, an integer token, a float token or one of the three special floating point literal values (Infinity, -Infinity or NaN) is used as the default value, it is interpreted in the same way as for a constant.

随意~引数の既定~値には、 `string$g ~tokも指定できる。 それは、次に従って決定される`文字列~型$の値をとる: ◎ Optional argument default values can also be specified using a string token, whose value is a string type determined as follows:

  1. %S := `string$g ~tokに合致する[ `Unicode ~scalar値$の並び ]から,先頭と末尾の `U+0022 QUOTATION MARK^char ( `"^c ) 文字を除去したもの ◎ Let S be the sequence of Unicode scalar values matched by the string token with its leading and trailing U+0022 QUOTATION MARK ('"') characters removed.
  2. `string$g ~tokの値は、引数の型に応じて,次で与えられる: ◎ Depending on the type of the argument:

    `DOMString$T
    `列挙$ 型
    %S を UTF-16 符号化したものに対応する, 16 ~bit無符号~整数~符号単位(以下、単に `符号単位@ と記される)の並び。 ◎ The value of the string token is the sequence of 16 bit unsigned integer code units (hereafter referred to just as code units) corresponding to the UTF-16 encoding of S.
    `ByteString$T
    %S を UTF-8 符号化したものに対応する, 8 ~bit無符号~整数~符号単位の並び。 ◎ The value of the string token is the sequence of 8 bit unsigned integer code units corresponding to the UTF-8 encoding of S.
    `USVString$T
    %S 。 ◎ The value of the string token is S.

`随意~引数$の型が`列挙$である場合、その`既定~値$に指定される値は,その列挙のいずれかの`列挙~値$で~MUST。 ◎ If the type of the optional argument is an enumeration, then its default value if specified MUST be one of the enumeration’s values.

`連列~型$(`~nullable$も含む)の随意~引数の既定~値には、 2 個の~tokによる `[]^c を利用して,その型と同じ型の空~連列~値を表現する値も指定できる。 `連列~型$(`~nullable$も含む)でない随意~引数に,この既定~値を指定しては~MUST_NOT。 ◎ Optional argument default values can also be specified using the two token value [], which represents an empty sequence value. The type of this value is the same the type of the optional argument it is being used as the default value of. That type MUST be a sequence type or a nullable type.

次の`~IDL片$は、2つの長さが異なる引数~listで呼出せる単独の`演算$を伴う`~ifc$を定義する: ◎ The following IDL fragment defines an interface with a single operation that can be invoked with two different argument list lengths:

interface ColorCreator {
  object createColor(double v1, double v2, double v3, optional double alpha);
};

それは、`多重定義$された2つの`演算$を持つ次の`~ifc$と等価になる: ◎ It is equivalent to an interface that has two overloaded operations:

interface ColorCreator {
  object createColor(double v1, double v2, double v3);
  object createColor(double v1, double v2, double v3, double alpha);
};

実装が`利用者~obj$上の`演算$の呼出しを試みた結果 (例えば,呼戻~objが実装に供されていて),例外が投出される場合、他から指定されない限り,その例外は[ 実装からその演算の呼出しを生じさせた,利用者~code ]まで伝播することになる。 同様に,演算の呼出しにより返される値を~IDL型に変換できない場合、それにより生じた例外も[ 実装からその演算の呼出しを試みさせた,利用者~code ]まで伝播することになる。 ◎ If an implementation attempts to invoke an operation on a user object (for example, when a callback object has been supplied to the implementation), and that attempt results in an exception being thrown, then, unless otherwise specified, that exception will be propagated to the user code that caused the implementation to invoke the operation. Similarly, if a value returned from invoking the operation cannot be converted to an IDL type, then any exception resulting from this will also be propagated to the user code that resulted in the implementation attempting to invoke the operation.

演算には、次の拡張属性を適用し得る: `Exposed$x, `NewObject$x, `SecureContext$x, `TreatNullAs$x, `Unforgeable$x 。 ◎ The following extended attributes are applicable to operations: [Exposed], [NewObject], [SecureContext], [TreatNullAs], [Unforgeable].

演算~引数には、次の拡張属性を適用し得る: `Clamp$x, `EnforceRange$x, `TreatNullAs$x 。 ◎ The following extended attributes are applicable to operation arguments: [Clamp], [EnforceRange], [TreatNullAs].

DefaultValue Operation SpecialOperation Specials Special OperationRest OptionalIdentifier ArgumentList Arguments Argument OptionalOrRequiredArgument ArgumentName Ellipsis ArgumentNameKeyword ReturnType

3.2.4. 特殊~演算

`特殊~演算@ は、[ その特殊~演算~宣言が現れる~ifc ]を実装する~obj上における[ 一定の種類の特殊な挙動 ]の宣言である。 `特殊~演算$は,演算~宣言において1個~以上の `特殊~keyword@ を利用して宣言される。 ◎ A special operation is a declaration of a certain kind of special behavior on objects implementing the interface on which the special operation declarations appear. Special operations are declared by using one or more special keywords in an operation declaration.

`特殊~演算$には、次の一覧に示す6種類がある。 一覧には、それぞれの種類の特殊~演算に対し,その宣言-時に利用される特殊~keyword, およびその特殊~演算の用途も示す: ◎ There are six kinds of special operations. The table below indicates for a given kind of special operation what special keyword is used to declare it and what the purpose of the special operation is:

`特殊~演算$◎Special operation ~keyword◎Keyword 用途◎Purpose
`取得子@ `getter^c ~prop取得1 のために~objが~indexingされる際の挙動を定義する。 ◎ Defines behavior for when an object is indexed for property retrieval.
`設定子@ `setter^c ~prop代入/作成 のために~objが~indexingされる際の挙動を定義する。 ◎ Defines behavior for when an object is indexed for property assignment or creation.
`削除子@ `deleter^c ~prop削除 のために~objが~indexingされる際の挙動を定義する。 ◎ Defines behavior for when an object is indexed for property deletion.
`旧来呼出子@ `legacycaller^c ~objが関数であったかのように~callされる際の挙動を定義する。 ◎ Defines behavior for when an object is called as if it were a function.
`文字列化子@ `stringifier^c ~objを `DOMString$T に変換する方法を定義する。 ◎ Defines how an object is converted into a DOMString.
`直列化子@ `serializer^c ~objを直列化形に変換する方法を定義する。 ◎ Defines how an object is converted into a serialized form.

すべての言語束縛が、[ これら6種類の,~objの特殊な挙動 ]すべてを~supportするわけではない。 `特殊~演算$が,識別子を伴わない演算を利用して宣言された場合、その個々の種類の特殊~演算を~supportしない言語束縛においては,単にその機能性が存在しないことになる。 ◎ Not all language bindings support all of the six kinds of special object behavior. When special operations are declared using operations with no identifier, then in language bindings that do not support the particular kind of special operations there simply will not be such functionality.

次の~IDL片は、取得子と設定子を伴う~ifcを定義する: ◎ The following IDL fragment defines an interface with a getter and a setter:

interface Dictionary {
  readonly attribute unsigned long propertyCount;

  getter double (DOMString propertyName);
  setter void (DOMString propertyName, double propertyValue);
};

~propの取得子や設定子を~supportしない言語束縛では、 `Dictionary^T を実装している~objはこの特殊な挙動を持たないことになる。 ◎ In language bindings that do not support property getters and setters, objects implementing Dictionary will not have that special behavior.

`特殊~演算$を`識別子$を伴わせて定義することは、その宣言から識別子のない特殊~演算を分離することと,等価である。 この書き方は、~ifcの演算についての注釈文の記述を単純化するために許容されている。 ◎ Defining a special operation with an identifier is equivalent to separating the special operation out into its own declaration without an identifier. This approach is allowed to simplify prose descriptions of an interface’s operations.

次の2つの~ifcは等価である: ◎ The following two interfaces are equivalent:

interface Dictionary {
  readonly attribute unsigned long propertyCount;

  getter double getProperty(DOMString propertyName);
  setter void setProperty(DOMString propertyName, double propertyValue);
};
interface Dictionary {
  readonly attribute unsigned long propertyCount;

  double getProperty(DOMString propertyName);
  void setProperty(DOMString propertyName, double propertyValue);

  getter double (DOMString propertyName);
  setter void (DOMString propertyName, double propertyValue);
};

1つの演算に同じ`特殊~keyword$が複数~回 現れては~MUST_NOT。 ◎ A given special keyword MUST NOT appear twice on an operation.

取得子, 設定子, 削除子は2つ系列に分類される:

  • `有名~prop取得子@, `有名~prop設定子@, `有名~prop削除子@ と呼ばれる,~prop名として `DOMString$T をとるもの。
  • `有index~prop取得子@, `有index~prop設定子@ と呼ばれる,~prop~indexとして `unsigned long$T をとるもの — 有index~propには,削除子は無い

詳細は `idl-indexed-properties$sec, `idl-named-properties$sec に。

◎ Getters and setters come in two varieties: ones that take a DOMString as a property name, known as named property getters and named property setters, and ones that take an unsigned long as a property index, known as indexed property getters and indexed property setters. There is only one variety of deleter: named property deleters. See section 3.2.4.4 and section 3.2.4.5 for details.

所与の`~ifc$上に存在する,[ `文字列化子$, `直列化子$, `削除子$ および, 各~系列の[ `取得子$, `設定子$ ]]は、それぞれ,高々1個までで~MUST。 旧来呼出子 については、多重定義された~callの挙動を指定する,複数のものが、同じ~ifc上に存在し得る。 ◎ On a given interface, there MUST exist at most one stringifier, at most one serializer, at most one named property deleter, and at most one of each variety of getter and setter. Multiple legacy callers can exist on an interface to specify overloaded calling behavior.

~ifcが[ いずれかの系列の`設定子$, あるいは`有名~prop削除子$ ]を持つ場合、同じ系列の`取得子$も持た~MUST。 ◎ If an interface has a setter of a given variety, then it MUST also have a getter of that variety. If it has a named property deleter, then it MUST also have a named property getter.

演算を利用して宣言される`特殊~演算$は,`可変個の引数をとる$ようにされたり, `随意~引数$を持っては~MUST_NOT。 ◎ Special operations declared using operations MUST NOT be variadic nor have any optional arguments.

`特殊~演算$は,`呼戻~ifc$上で宣言されては~MUST_NOT。 ◎ Special operations MUST NOT be declared on callback interfaces.

~objが,所与の`特殊~演算$を定義する複数の`~ifc$を実装する場合、その演算に対し,どの特殊~演算が呼出されるかは 未定義である。 ◎ If an object implements more than one interface that defines a given special operation, then it is undefined which (if any) special operation is invoked for that operation.

3.2.4.1. 旧来呼出子

`~ifc$が1個~以上の`旧来呼出子$を持つとき、その~ifcを実装する~objは,それらが関数であったかのように~callし得ることを指示する。 上に示された様に,旧来呼出子は `legacycaller^c ~keywordを伴って宣言される`演算$を利用して指定できる。 ◎ When an interface has one or more legacy callers, it indicates that objects that implement the interface can be called as if they were functions. As mentioned above, legacy callers can be specified using an operation declared with the legacycaller keyword.

legacycaller `return-type^i `identifier^i(`arguments…^i);
legacycaller `return-type^i (`arguments…^i);

~ifcに複数の`旧来呼出子$が指定されている場合、その~objが関数であったかのように~callされる際に,どの旧来呼出子が呼出されるか決定するときには、`多重定義~解決~algo$が利用される。 ◎ If multiple legacy callers are specified on an interface, overload resolution is used to determine which legacy caller is invoked when the object is called as if it were a function.

`旧来呼出子$は、`~promise型$を返し得るように定義されては~MUST_NOT。 ◎ Legacy callers MUST NOT be defined to return a promise type.

`旧来呼出子$は望ましくない特色機能としてあまねく認識されている。 それらはもっぱら,旧来の Web ~platform特色機能を指定できるようにするために存在する。 旧来呼出子は、旧来の API の挙動の指定が要求されていない限り,仕様に利用される~SHOULD_NOT。 その場合においても,先に進む前に public-script-coord@w3.org ~mailing-listにて論を交わすべきである。 ◎ Legacy callers are universally recognised as an undesirable feature. They exist only so that legacy Web platform features can be specified. Legacy callers SHOULD NOT be used in specifications unless required to specify the behavior of legacy APIs, and even then this should be discussed on the public-script-coord@w3.org mailing list before proceeding.

次の`~IDL片$は、`旧来呼出子$を伴う`~ifc$を定義する。 ◎ The following IDL fragment defines an interface with a legacy caller.

interface NumberQuadrupler {
  // この演算は単純に %x を 4 倍にして返す。
  legacycaller double compute(double x);
};

この~ifcを~supportする~JS実装では,関数として~callされる `NumberQuadrupler^T を実装する`~platform~obj$が許容されることになるであろう: ◎ An ECMAScript implementation supporting this interface would allow a platform object that implements NumberQuadrupler to be called as a function:

var f = getNumberQuadrupler();  // `NumberQuadrupler^T の~instanceを得る。

f.compute(3);                   // これは `12^v に評価される。
f(3);                           // これも `12^v に評価される。
3.2.4.2. 文字列化子

`~ifc$が`文字列化子$を持つとき、 その~ifcを実装する~objは,文字列への既定でない変換を持つことになる。 上に示した様に、文字列化子は `stringifier^c ~keywordを伴って宣言される`演算$を利用して,指定できる。 ◎ When an interface has a stringifier, it indicates that objects that implement the interface have a non-default conversion to a string. As mentioned above, stringifiers can be specified using an operation declared with the stringifier keyword.

stringifier DOMString `identifier^i();
stringifier DOMString ();

`文字列化子$の宣言-時に利用された演算が`識別子$を持たない場合、~ifcに付随する注釈文において,~ifcの `文字列化の挙動@ が定義され~MUST。 演算が識別子を持つ場合、その演算の呼出しにより,~objは文字列に変換される。 ◎ If an operation used to declare a stringifier does not have an identifier, then prose accompanying the interface MUST define the stringification behavior of the interface. If the operation does have an identifier, then the object is converted to a string by invoking the operation to obtain the string.

演算により宣言される`文字列化子$は、引数をとらず, `DOMString$T を返すように,宣言され~MUST。 ◎ Stringifiers declared with operations MUST be declared to take zero arguments and return a DOMString.

略記法として、 `stringifier^c ~keywordが,識別子を伴わない演算により宣言される場合、その演算の`返値型$, および引数~listを省略できる。 ◎ As a shorthand, if the stringifier keyword is declared using an operation with no identifier, then the operation’s return type and argument list can be omitted.

stringifier;

次の2つの~ifcは等価である: ◎ The following two interfaces are equivalent:

interface A {
  stringifier DOMString ();
};
interface A {
  stringifier;
};

`stringifier^c ~keywordは `属性$上に置くこともできる。 この場合、その属性の値が,~objから文字列への変換-を与える。 `stringifier^c ~keywordが[[ `DOMString$T/`USVString$T として宣言されていない属性 ]や `静的~属性$ ]上に置かれては~MUST_NOT。 ◎ The stringifier keyword can also be placed on an attribute. In this case, the string to convert the object to is the value of the attribute. The stringifier keyword MUST NOT be placed on an attribute unless it is declared to be of type DOMString or USVString. It also MUST NOT be placed on a static attribute.

stringifier attribute DOMString `identifier^i;
Stringifier StringifierRest

次の`~IDL片$は、 `name^M 属性の値に文字列化する~ifcを定義する: ◎ The following IDL fragment defines an interface that will stringify to the value of its name attribute:

[Constructor]
interface Student {
  attribute unsigned long id;
  stringifier attribute DOMString name;
};

~JS言語束縛においては、文字列が期待されている文脈において `Student^T ~objが利用されたときの結果は、その~objの `name^l ~propの値になる: ◎ In the ECMAScript binding, using a Student object in a context where a string is expected will result in the value of the object’s “name” property being used:

var s = new Student();
s.id = 12345678;
s.name = '周杰倫';

var greeting = 'こんにちは、 ' + s + ' さん。';
    // %greeting は `こんにちは、 周杰倫 さん。^l になる。

次の`~IDL片$は、~IDL自身には指定されない独自の文字列化の挙動を持つ~ifcを定義する。 ◎ The following IDL fragment defines an interface that has custom stringification behavior that is not specified in the IDL itself.

[Constructor]
interface Student {
  attribute unsigned long id;
  attribute DOMString? familyName;
  attribute DOMString givenName;

  stringifier DOMString ();
};

したがって、例えば次の段落の様な,文字列化の挙動を説明する注釈文が要求される: ◎ Thus, prose is required to explain the stringification behavior, such as the following paragraph:

`Student^T ~ifc を実装する~objを文字列化した結果は、 `familyName^M 属性の値が `null^V の場合は `givenName^M 属性の値,他の場合は[ `givenName^M 属性の値, 1個の space 文字, `familyName^M 属性の値 ]の連結にならなければ~MUST_NOT。 ◎ Objects that implement the Student interface must stringify as follows. If the value of the familyName attribute is null, the stringification of the object is the value of the givenName attribute. Otherwise, if the value of the familyName attribute is not null, the stringification of the object is the concatenation of the value of the givenName attribute, a single space character, and the value of the familyName attribute.

この~IDLの~JS実装は、次に従って挙動することになる: ◎ An ECMAScript implementation of the IDL would behave as follows:

var s = new Student();
s.id = 12345679;
s.familyName = 'Smithee';
s.givenName = 'Alan';

var greeting = 'こんにちは、 ' + s + ' さん。';
    // %greeting は `こんにちは、 Alan Smithee さん^l になる。
3.2.4.3. 直列化子

`~ifc$が`直列化子$を持つとき、その~ifcを実装する~objが,自身を直列化形に変換する仕方を提供することを指示する。 直列化子は `serializer^c ~keywordを利用して宣言できる。 ◎ When an interface has a serializer, it indicates that objects provide a way for them to be converted into a serialized form. Serializers can be declared using the serializer keyword:

serializer;

この仕方で`直列化子$を宣言する~ifcにおいては、付随する注釈文にて, その~ifcの `直列化-時の挙動@ が定義され~MUST。 直列化-時の挙動は、次のいずれかの型による `直列化形の値@ を返すものとして定義される: ◎ Prose accompanying an interface that declares a serializer in this way MUST define the serialization behavior of the interface. Serialization behavior is defined as returning a serialized value of one of the following types:

  • 次のいずれも満たすような,一連の~key-valueからなる~map

    • どの~keyも ~map内で一意な `DOMString$T 値である
    • どの~valueも `直列化形の値$である
    ◎ a map of key–value pairs, where the keys are DOMString values (unique in the map) and the values are serialized values
  • 一連の`直列化形の値$からなる,~list ◎ a list of serialized values
  • `DOMString$T 値 ◎ a DOMString value
  • `unrestricted double$T 値 ◎ an unrestricted double value
  • `boolean$T 値 ◎ a boolean value
  • `null^V 値 ◎ the null value

[ 言語束縛において,`直列化-時の挙動$が~obj上にてどのように可用にされるか ], および[ 抽象的な`直列化形の値$がどのようにして適切な具体的な値に変換されるか ]については、言語束縛~特有になる。 ◎ How the serialization behavior is made available on an object in a language binding, and how exactly the abstract serialized value is converted into an appropriate concrete value, is language binding specific.

~JS言語束縛においては、`直列化-時の挙動$は,[ `直列化形の値$を[[ `JSON.stringify^c 関数により JSON に直列化し得る ]ような~JS値 ]に変換したもの ]を返すような `toJSON^c ~methとして,公開される。 詳細は `es-serializer$sec に。 ◎ In the ECMAScript language binding, serialization behavior is exposed as a toJSON method which returns the serialized value converted into an ECMAScript value that can be serialized to JSON by the JSON.stringify function. See section 4.6.7.2 below for details.

`直列化-時の挙動$は、別途の注釈文を与えずに,~IDLの中で直接的に指定することもできる。 そのためには、 ~keyword `serializer^c と 文字 `U+003D EQUALS SIGN ("=")^char に続けて,以下に述べる6種の形をとり得る `直列化~pattern@ を記す: ◎ Serialization behavior can also be specified directly in IDL, rather than separately as prose. This is done by following the serializer keyword with a U+003D EQUALS SIGN ("=") character and a serialization pattern, which can take one of the following six forms:

~ifcからの,ゼロ個~以上の属性に対応する~entryを伴う~map ①: ◎ ↓
または、① に加え,被継承~ifc からの属性に対応する~entryも伴う~map: ◎ A map with entries corresponding to zero or more attributes from the interface, and optionally attributes from an inherited interface:
serializer = { `attribute-identifier^i, `attribute-identifier^i, … }; // ①
serializer = { inherit, `attribute-identifier^i, `attribute-identifier^i, … };

どの識別子も,~ifc上で宣言された属性の識別子で~MUST。 識別されるどの属性も,`直列化可能な型$を持た~MUST。 ◎ Each identifier MUST be the identifier of an attribute declared on the interface. The identified attributes all MUST have a serializable type.

`inherit^c ~keywordは、[ ~ifcが`直列化子$を定義する別の~ifcを継承し, かつ そのような~ifcのうち最も末端のものが[ この形, または次項の形(すなわち, `{ attribute }^c ) ]による`直列化~pattern$を利用して直列化子を定義している ]場合を除き,利用されては~MUST_NOT。 ◎ The inherit keyword MUST NOT be used unless the interface inherits from another that defines a serializer, and the closest such interface defines its serializer using this serialization pattern form or the following form (i.e. { attribute }).

この形の直列化~patternに対する`直列化-時の挙動$は、次で与えられる: ◎ The serialization behavior for this form of serialization pattern is as follows:

  1. %map := 空の~map ◎ Let map be an empty map.
  2. ~IF `inherit^c ~keywordが利用されている ~THEN %map ← `直列化子$を宣言する最も末端の被継承~ifc の`直列化-時の挙動$の結果 ◎ If the inherit keyword was used, then set map to be the result of the serialization behavior of the closest inherited interface that declares a serializer.
  3. ~FOR 直列化~pattern内の~EACH ( 属性~識別子 %i ) に対し,順に: ◎ For each attribute identifier i in the serialization pattern, in order:

    1. %map 内から[ ~key ~EQ %i ]なる~entryをすべて除去する ◎ Remove any entry in map with key name i.
    2. %V := 識別子 %i の属性の値 ◎ Let V be the value of the attribute with identifier i.
    3. [ ~key ~EQ %i, ~value ~EQ [ %V を`直列化形の値に変換-$した結果 ]]なる~entryを %map に追加する ◎ Add an entry to map whose key name is i and whose value is result of converting V to a serialized value.
  4. ~RET %map ◎ Return map.
~ifcからの,すべての[ `直列化可能な型$を持つ属性 ]に対応する~entryを伴う~map ②: ◎ ↓
または、② に加え,被継承~ifc からの属性に対応する~entryも伴う~map: ◎ A map with entries corresponding to all attributes from the interface that have a serializable type, and optionally attributes from an inherited interface:
serializer = { attribute }; // ②
serializer = { inherit, attribute };

`inherit^c ~keywordは、[ ~ifcが`直列化子$を定義する別の~ifcを継承し, かつ そのような~ifcのうち最も末端のものが[ この形, または前項の形 ]による`直列化~pattern$を利用して直列化子を定義している ]場合を除き,利用されては~MUST_NOT。 ◎ The inherit keyword MUST NOT be used unless the interface inherits from another that defines a serializer, and the closest such interface defines its serializer using this serialization pattern form or the previous form.

  1. ~FOR ~ifc上の ~EACH ( `直列化可能な型$を持つ属性の識別子 %i ) に対し,それが~ifc上に現れる順に: ◎ For each identifier i of an attribute on the interface whose type is a serializable type, in the order they appear on the interface:

`有名~prop$に対応している~entryを伴う~map: ◎ A map with entries corresponding to the named properties:
serializer = { getter };

この形は、[ ~ifcまたはそれが継承する~ifcが有名~propを~supportする ], かつ[ `有名~prop取得子$の返値型が直列化可能である ]場合を除き,利用されては~MUST_NOT。 ◎ This form MUST NOT be used unless the interface or one it inherits from supports named properties and the return type of the named property getter is a serializable type.

  1. ~FOR ~obj上の~EACH ( `被support~prop名$ %n ) に対し,順に: ◎ For each supported property name n on the object, in order:

    1. %V := 名前 %n の有名~propの値 ◎ Let V be the value of the named property with name n.
~ifc上のゼロ個~以上の属性の値の~list: ◎ A list of value of zero or more attributes on the interface:
serializer = [ `attribute-identifier^i, `attribute-identifier^i, … ];
  1. %list := 空~list ◎ Let list be an empty list.
  2. ~FOR 直列化~pattern内の ~EACH ( 属性~識別子 %i ) に対し,順に: ◎ For each attribute identifier i in the serialization pattern:

    1. %V を`直列化形の値に変換-$した結果の値を %list に付加する ◎ Append to list the value that is the result of converting V to a serialized value.
  3. ~RET %list ◎ Return list.
`有index~prop$に対応している~entryの~list ◎ A list with entries corresponding to the indexed properties:
serializer = [ getter ];

この形は、[ ~ifcまたはそれが継承する~ifcが`有index~propを~supportする$ ], かつ[ `有index~prop取得子$の返値型が直列化可能な型である ]場合を除き,利用されては~MUST_NOT。 ◎ This form MUST NOT be used unless the interface or one it inherits from supports indexed properties and the return type of the indexed property getter is a serializable type.

  1. %i :← 0 ◎ Let i be 0.
  2. ~WHILE %i ≤ ~obj上の`被support~prop~index$の最大: ◎ While i is less than or equal to the greatest supported property index on the object:

    1. %V := [ %i は`被support~prop~index$であるならば ~index %i に位置する有index~propの値 / ~ELSE_ `null^V ] ◎ Let V be the value of the indexed property with index i if i is a supported property index, or null otherwise.
    2. %i ← %i + 1 ◎ Set i to i + 1.
単独の属性: ◎ A single attribute:
serializer = `attribute-identifier^i;

識別子は,~ifc上で宣言された属性の識別子で~MUST。 その属性は,`直列化可能な型$を持た~MUST。 ◎ The identifier MUST be the identifier of an attribute declared on the interface, and this attribute MUST have a serializable type.

  1. ~RET 指定された識別子を伴う属性の値を`直列化形の値に変換-$した結果 ◎ Let V be the value of the attribute with the specified identifier. ◎ Return the result of converting V to a serialized value.

一連の~entryは,特定0の順序により~mapに追加される。 ~JS言語束縛においては,~propが~objに追加される順序に従うものと定義される。 この順序は `JSON.stringify^c から生成される直列化に波及するので。 ◎ Entries are added to maps in a particular order so that in the ECMAScript language binding it is defined what order properties are added to objects. This is because this order can influence the serialization that JSON.stringify can produce.

各種 `直列化可能な型@, および それらを `直列化形の値に変換-@ する方法は、次で与えられる: ◎ The list of serializable types and how they are converted to serialized values is as follows:

`long long$T
`unsigned long long$T
最も近い等価な `double$T 値に変換される( この~IDL整数~型を~JS `Number^t 値に変換する ときと同様に) ◎ converted by choosing the closest equivalent double value (as when converting a long long to an ECMAScript Number value) ◎ converted by choosing the closest equivalent double value (as when converting a unsigned long long to an ECMAScript Number value)
他のすべての`整数~型$
`float$T
等価な `double$T 値に変換される ◎ converted by choosing the equivalent double value
`double$T
`boolean$T
`DOMString$T
それぞれの型の,同じ値 ◎ the same value of the respective type
`列挙~型$◎an enumeration type
等価な `DOMString$T 値 ◎ the equivalent DOMString value
`USVString$T◎USVString
所与の`Unicode ~scalar値$の並びを UTF-16 に符号化して生産される `DOMString$T ◎ the DOMString produced by encoding the given sequence of Unicode scalar values in UTF-16
`ByteString$T◎ByteString
各~符号単位と対応する~byteが数として同じであるような,等価な `DOMString$T 値 ◎ the equivalent DOMString value where each code unit has the same value as the corresponding byte value
`~nullable型$であって,その`内縁~型$は直列化可能であるもの ◎a nullable serializable type
値が `null^T ならば `null^T に変換され、他の場合は,その`内縁~型$に従って変換される ◎ converted to null if that is its value, otherwise converted as per its inner type
`共用体~型$であって,そのどの`~mb型$も直列化可能であるもの ◎ a union type where all of its member types are serializable types
その`固有型$に従って変換される ◎ converted as per its specific type
`連列~型$であって,その要素~型は直列化可能であるもの ◎ a sequence type that has a serializable type as its element type
~listに変換される。 その各~要素は,連列の中の対応する要素を`直列化形の値に変換-$した結果で与えられる。 ◎ converted to a list where each element is the result of converting its corresponding sequence element to a serialized value
`辞書~型$であって,そのどの`辞書~mb$も直列化可能な型であるもの ◎ a dictionary where all of its members have serializable types
~mapに変換される。 その一連の~entryは、辞書に`在する$各~mb %m に対する~entry[ ~key ~EQ %m の識別子, ~value ~EQ [ %m の値を`直列化形の値に変換-$した結果 ]]で与えられる。 ◎ converted to a map consisting of an entry for each dictionary member that is present, where the entry’s key is the identifier of the dictionary member and its value is the result of converting the dictionary member’s value to a serializable type
`~ifc型$であって,`直列化子$を持つもの ◎ an interface type that has a serializer
~objの直列化子を呼出して変換される ◎ converted by invoking the object’s serializer

`直列化子$は `serializer^c ~keywordを伴う`演算$を利用して指定することもできる: ◎ Serializers can also be specified using an operation with the serializer keyword:

serializer `type^i `identifier^i();

演算を伴って宣言される`直列化子$は、ゼロ個の引数をとり, かつ `直列化可能な型$を返すものとして,宣言され~MUST。 ◎ Serializers declared with operations MUST be declared to take zero arguments and return a serializable type.

`直列化子$が演算を伴って宣言されている~ifcにおける,`直列化-時の挙動$ は、その演算を呼出して返される値を`直列化形の値に変換-$した結果で与えられる。 ◎ The serialization behavior of the interface with a serializer declared with an operation is the result of converting the value returned from invoking the operation to a serialized value.

Serializer SerializerRest SerializationPattern SerializationPatternMap SerializationPatternList Identifiers

次の `~IDL片$は、注釈文にて定義される`直列化子$を持つ, `Transaction^T ~ifcを定義する: ◎ The following IDL fragment defines an interface Transaction that has a serializer defines in prose:

interface Transaction {
  readonly attribute Account from;
  readonly attribute Account to;
  readonly attribute double amount;
  readonly attribute DOMString description;
  readonly attribute unsigned long number;

  serializer;
};

interface Account {
  DOMString name;
  unsigned long number;
};

直列化子は、次に従うように定義できる: ◎ The serializer could be defined as follows:

`Transaction^T ~ifcの`直列化-時の挙動$は、次の~algoで与えられる。 ここで %O は `Transaction^T を実装する~objであるとする: ◎ The serialization behavior of the Transaction interface is to run the following algorithm, where O is the object that implements Transaction:

  1. [ ~key ~EQ `from^l, ~value ~EQ [ %O 上の `from^M 属性から参照されている `Account^T ~obj上の `number^M 属性~値に対する`直列化形の値$ ]]なる~entryを %map に追加する。 ◎ Add an entry to map whose key is “from” and whose value is the serialized value of the number attribute on the Account object referenced by the from attribute on O.
  2. [ ~key ~EQ `to^l, ~value ~EQ [ %O 上の `to^M 属性から参照されている `Account^T ~obj上の `number^M 属性~値に対する`直列化形の値$ ]]なる~entryを %map に追加する。 ◎ Add an entry to map whose key is “to” and whose value is the serialized value of the number attribute on the Account object referenced by the from attribute on O.
  3. 属性 `amount^c, `description^c のそれぞれに対し,[ ~key ~EQ その属性の`識別子$, ~value ~EQ [ %O 上のその属性~値に対する`直列化形の値$ ]]なる~entryを %map に追加する。 ◎ For both of the attributes amount and description, add an entry to map whose key is the identifier of the attribute and whose value is the serialized value of the value of the attribute on O.

`Account^T ~obj自身を直列化可能にしてもよいのであれば、`直列化~pattern$の利用により,注釈文による`直列化-時の挙動$を定義せずに済ませられるようになる: ◎ If it was acceptable for Account objects to be serializable on their own, then serialization patterns could be used to avoid having to define the serialization behavior in prose:

interface Transaction {
  readonly attribute Account from;
  readonly attribute Account to;
  readonly attribute double amount;
  readonly attribute DOMString description;
  readonly attribute unsigned long number;

  serializer = { from, to, amount, description };
};

interface Account {
  DOMString name;
  unsigned long number;

  serializer = number;
};

~JS言語束縛においては、 `Transaction^T ~obj上に `toJSON^c ~methが存在することになる: ◎ In the ECMAScript language binding, there would exist a toJSON method on Transaction objects:

// `Transaction^T の~instanceを取得-
var txn = getTransaction();


/*  次の様な~objに評価される:
 {
   from: 1234
   to: 5678
   amount: 110.75
   description: "dinner"
 }
*/

txn.toJSON();

// 次の様な文字列に評価される:
// '{"from":1234,"to":5678,"amount":110.75,"description":"dinner"}'
JSON.stringify(txn);
3.2.4.4. 有index~prop

`有index~prop取得子$を定義する`~ifc$は、 `有index~propを~supportする@ という。 ◎ An interface that defines an indexed property getter is said to support indexed properties.

~ifcが`有index~propを~supportする$場合、その~ifc定義には,所与の任意の時点で~objに~indexingし得る~indexについての記述も付随してい~MUST。 これらの~indexは `被support~prop~index@ と呼ばれる。 ◎ If an interface supports indexed properties, then the interface definition MUST be accompanied by a description of what indices the object can be indexed with at any given time. These indices are called the supported property indices.

`有index~prop取得子$は、1個の `unsigned long$T 引数をとるものとして宣言され~MUST。 有index~propの設定子は、2個の引数をとり, 第一~引数が `unsigned long$T をとるものとして宣言され~MUST。 ◎ Indexed property getters MUST be declared to take a single unsigned long argument. Indexed property setters MUST be declared to take two arguments, where the first is an unsigned long.

getter `type^i `identifier^i(unsigned long `identifier^i);
setter `type^i `identifier^i(unsigned long `identifier^i, `type^i `identifier^i);

getter `type^i (unsigned long `identifier^i);
setter `type^i (unsigned long `identifier^i, `type^i `identifier^i);

次の要件が,有index~propの[ 取得子, 設定子 ]の定義に適用される: ◎ The following requirements apply to the definitions of indexed property getters and setters:

  • `有index~prop取得子$の宣言に利用された`演算$が`識別子$を:

    • 持つ場合、~objに対する,所与の`被support~prop~index$による~indexingの際に返される値は、その演算を,その~indexを唯一の引数に渡して呼出したときと同じになる。
    • 持たない場合、その~ifc定義には,所与の~indexに対し `有index~propの値を決定する@ 方法についての記述も付随してい~MUST。
    ◎ If an indexed property getter was specified using an operation with an identifier, then the value returned when indexing the object with a given supported property index is the value that would be returned by invoking the operation, passing the index as its only argument. If the operation used to declare the indexed property getter did not have an identifier, then the interface definition must be accompanied by a description of how to determine the value of an indexed property for a given index.
  • `有index~prop設定子$の宣言に利用された`演算$が`識別子$を:

    • 持つ場合、~objに対する,所与の ( `被support~prop~index$, 値 ) による,~prop代入のための~indexingの際に生じる挙動は、その演算の第一~引数に~indexを, 第二~引数に値を渡して呼出したときと同じになる。
    • 持たない場合、その~ifc定義には,所与の ( ~prop~index, 値 ) に対し[ `既存の有index~propを設定する@ 方法, および `新たな有index~propを設定する@ 方法 ]についての記述も付随してい~MUST。
    ◎ If an indexed property setter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property assignment with a given supported property index and value is the same as if the operation is invoked, passing the index as the first argument and the value as the second argument. If the operation used to declare the indexed property setter did not have an identifier, then the interface definition must be accompanied by a description of how to set the value of an existing indexed property and how to set the value of a new indexed property for a given property index and value.

`有index~prop$の[ 取得子/設定子 ]が`識別子$を伴う`演算$を利用して指定されている場合、~objに対する[ `被support~prop~index$でない整数 ]による~indexingは,その~indexによる演算の呼出しと同じ挙動をなぞるとは限らないことに注意。 この場合における実際の挙動は、言語束縛~特有になる。 ◎ Note that if an indexed property getter or setter is specified using an operation with an identifier, then indexing an object with an integer that is not a supported property index does not necessarily elicit the same behavior as invoking the operation with that index. The actual behavior in this case is language binding specific.

~JS言語束縛においては,~~通常の~prop検索が行われる。 例えば次の~IDLでは: ◎ In the ECMAScript language binding, a regular property lookup is done. For example, take the following IDL:

interface A {
  getter DOMString toWord(unsigned long index);
};

`A^T を実装している~objの`被support~prop~index$は,範囲[ 0 ≤ %index < 2 ]とする。 また、 `toWord^M は,引数の数字を英単語に変換した文字列を返すように定義されているとする。 範囲~外の~indexにより`演算$を呼出したときの挙動は,~objの直接的な~indexingとは異なる: ◎ Assume that an object implementing A has supported property indices in the range 0 ≤ index < 2. Also assume that toWord is defined to return its argument converted into an English word. The behavior when invoking the operation with an out of range index is different from indexing the object directly:

var a = getA();

a.toWord(0);  // `zero^l  に評価される。
a[0];         // これも `zero^l に評価される。

a.toWord(5);  // `five^l に評価される。
a[5];         // ~prop `5^l は存在しないので `undefined^v に評価される。

次の`~IDL片$は 名前または~indexによる値の取得0と設定を許容する `OrderedMap^T ~ifcを定義する: ◎ The following IDL fragment defines an interface OrderedMap which allows retrieving and setting values by name or by index number:

interface OrderedMap {
  readonly attribute unsigned long size;

  getter any getByIndex(unsigned long index);
  setter void setByIndex(unsigned long index, any value);

  getter any get(DOMString name);
  setter void set(DOMString name, any value);
};

すべての特殊~演算が識別子を伴う演算を利用して宣言されているので、追加を要する唯一の注釈文は,これらの集合が持つ~keyを与える記述になる。 `OrderedMap^T 内に存在しない項目に対する検索が試みられた場合に対し, `get()^c 演算が `null^V を返すように定義されているとするとき、次の2~~文で足りるであろう: ◎ Since all of the special operations are declared using operations with identifiers, the only additional prose that is necessary is that which describes what keys those sets have. Assuming that the get() operation is defined to return null if an attempt is made to look up a non-existing entry in the OrderedMap, then the following two sentences would suffice:

`OrderedMap^T を実装する~obj %map は、範囲[ 0 ≤ %index < `map.size^c ]の`有index~propを~supportする$。 ◎ An object map implementing OrderedMap supports indexed properties with indices in the range 0 ≤ index < map.size.

そのような~objは、 `get()^c に渡されたときに非 `null^V 値が返されるような,どの名前に対しても、有名~propを~supportする。 ◎ Such objects also support a named property for every name that, if passed to get(), would return a non-null value.

`es-platform-objects$sec にて述べられるように、~JS実装は[ 有名, 有index ]いずれの~propの集合に対しても、その集合に属する各項に対応する~propを[ `OrderedMap^T を実装している`~platform~obj$ ]上に,作成することになるであろう。 下に示すように、これらの~propを,~objの~methの呼出しと同じ仕方で,~objとのやり取りに利用できる: ◎ As described in section 4.8, an ECMAScript implementation would create properties on a platform object implementing OrderedMap that correspond to entries in both the named and indexed property sets. These properties can then be used to interact with the object in the same way as invoking the object’s methods, as demonstrated below:

// %map は `OrderedMap^T ~ifcを実装する~platform~objであるとする。
var map = getOrderedMap();
var x, y;

x = map[0];       /*
                   `map.length^c > 0 ならば、次と等価になる:
                   
                     `x = map.getByIndex(0)^c
                   
                   (名前 `0^l の~propが %map 上に置かれるので)。
                   他の場合、名前 `0^l の~propは %map 上にないので,
                   %x は `undefined^v に設定されることになる。 */

map[1] = false;   /*
                   これは、次と等価な動作になる:
                  
                     `map.setByIndex(1, false)^c
                   */

y = map.apple;    /*
                   名前 `apple^l の有名~propが存在する場合、
                   名前 `apple^l の~propが %map 上にあり,
                   次と等価な動作になる:
                  
                     `y = map.get('apple')^c
                  
                   他の場合、名前 `apple^l の~propは %map 上にないので,
                   %y は `undefined^v に設定されることになる。 */

map.berry = 123;  /*
                   これは、次と等価な動作になる:
                  
                     `map.set('berry', 123)^c
                   */

delete map.cake;  /*
                   有名~prop `cake^l が存在するなら、
                   `cake^l ~propが削除され,
                   次と等価な動作になる:
                  
                     `map.remove("cake")^c
                   */

3.2.4.5. 有名~prop

`有名~prop取得子$を定義する`~ifc$は、 `有名~propを~supportする@ という。 ◎ An interface that defines a named property getter is said to support named properties.

`有名~propを~supportする$~ifcの~ifc定義には、[ 所与の任意の時点で~objに~indexingし得るような,順序付けられた名前の集合 ]についての記述も付随してい~MUST。 これらの名前は、 `被support~prop名@ と呼ばれる。 ◎ If an interface supports named properties, then the interface definition MUST be accompanied by a description of the ordered set of names that can be used to index the object at any given time. These names are called the supported property names.

有名~propの取得子と削除子は、1個の `DOMString$T を引数にとるものとして宣言され~MUST。 有名~propの設定子は、2個の引数をとり,第一~引数に `DOMString$T をとるものとして宣言され~MUST。 ◎ Named property getters and deleters MUST be declared to take a single DOMString argument. Named property setters MUST be declared to take two arguments, where the first is a DOMString.

getter `type^i `identifier^i(DOMString `identifier^i);
setter `type^i `identifier^i(DOMString `identifier^i, `type^i `identifier^i);
deleter `type^i `identifier^i(DOMString `identifier^i);

getter `type^i (DOMString `identifier^i);
setter `type^i (DOMString `identifier^i, `type^i `identifier^i);
deleter `type^i (DOMString `identifier^i);

次の要件が,有名~propの[ 取得子, 設定子, 削除子 ]の定義に適用される: ◎ The following requirements apply to the definitions of named property getters, setters and deleters:

  • `有名~prop取得子$の宣言に利用された`演算$が`識別子$を:

    • 持つ場合、~objに対する,所与の`被support~prop名$による~indexingの際に返される値は、その演算を,その~prop名を唯一の引数に渡して呼出したときと同じになる。
    • 持たない場合、その~ifc定義には,所与の~prop名に対し `有名~propの値を決定する@ 方法についての記述も付随してい~MUST。
    ◎ If a named property getter was specified using an operation with an identifier, then the value returned when indexing the object with a given supported property name is the value that would be returned by invoking the operation, passing the name as its only argument. If the operation used to declare the named property getter did not have an identifier, then the interface definition must be accompanied by a description of how to determine the value of a named property for a given property name.
  • `有名~prop設定子$の宣言に利用された`演算$が`識別子$を:

    • 持つ場合、~objに対する,所与の ( `被support~prop名$, 値 ) による,~prop代入のための~indexingの際に生じる挙動は、 その演算の第一~引数に~prop名を, 第二~引数に値を渡して呼出したときと同じになる。
    • 持たない場合、その~ifc定義には,所与の ( ~prop名, 値 ) に対し[ `既存の有名~propを設定する@ 方法, および `新たな有名~propを設定する@ 方法 ]についての記述も付随してい~MUST。
    ◎ If a named property setter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property assignment with a given supported property name and value is the same as if the operation is invoked, passing the name as the first argument and the value as the second argument. If the operation used to declare the named property setter did not have an identifier, then the interface definition must be accompanied by a description of how to set the value of an existing named property and how to set the value of a new named property for a given property name and value.
  • `有名~prop削除子$の宣言に利用された`演算$が`識別子$を:

    • 持つ場合、~objに対する,所与の`被support~prop名$による,~prop削除のための~indexingの際に生じる挙動は、その演算を,その~prop名を唯一の引数に渡して呼出したときと同じになる。
    • 持たない場合、その~ifc定義には,所与の~prop名に対し `既存の有名~propを削除する@ 方法についての記述も付随してい~MUST。
    ◎ If a named property deleter was specified using an operation with an identifier, then the behavior that occurs when indexing the object for property deletion with a given supported property name is the same as if the operation is invoked, passing the name as the only argument. If the operation used to declare the named property deleter did not have an identifier, then the interface definition must be accompanied by a description of how to delete an existing named property for a given property name.

`有index~prop$のときと同様に,`有名~prop$の[ 取得子/設定子/削除子 ]が`識別子$を伴う`演算$を利用して指定された場合、~objに対する[ `被support~prop名$でない名前 ]による~indexingは,その名前による演算の呼出しと同じ挙動をなぞるとは限らないことに注意。 挙動は、言語束縛~特有になる。 ◎ As with indexed properties, if an named property getter, setter or deleter is specified using an operation with an identifier, then indexing an object with a name that is not a supported property name does not necessarily elicit the same behavior as invoking the operation with that name; the behavior is language binding specific.

3.2.5. 静的~属性と静的~演算

`静的~属性@, `静的~演算@ は、それが宣言される`~ifc$の個々の~instance上には結付けられないものであり、代わりに,その ~ifc自身に結付けられる。 静的~属性と静的~演算は,それらの宣言の中で `static^c ~keywordを利用して宣言される。 ◎ Static attributes and static operations are ones that are not associated with a particular instance of the interface on which it is declared, and is instead associated with the interface itself. Static attributes and operations are declared by using the static keyword in their declarations.

静的~演算の呼出しや静的~属性の取得-/設定-が,~ifcの~instanceへの参照を通して可能かどうかは、言語束縛~特有になる。 ◎ It is language binding specific whether it is possible to invoke a static operation or get or set a static attribute through a reference to an instance of the interface.

静的~演算/静的~属性は,`呼戻~ifc$上で宣言されては~MUST_NOT。 ◎ Static attributes and operations MUST NOT be declared on callback interfaces.

StaticMember StaticMemberRest

次の`~IDL片$は、静的~演算が宣言されている `Circle^T ~ifcを定義する: ◎ The following IDL fragment defines an interface Circle that has a static operation declared on it:

interface Point { /* ... */ };

interface Circle {
  attribute double cx;
  attribute double cy;
  attribute double radius;

  static readonly attribute long triangulationCount;
  static Point triangulate(Circle c1, Circle c2, Circle c3);
};

~JS言語束縛においては、 `Circle^T に対応する`~ifc~obj$上に, `triangulate^M に対応する `Function^t ~obj, および `triangulationCount^M に対応する~accessor~prop が存在することになる: ◎ In the ECMAScript language binding, the Function object for triangulate and the accessor property for triangulationCount will exist on the interface object for Circle:

var circles = getCircles();        // `Circle^T ~objの `Array^t

typeof Circle.triangulate;         // `function^l に評価される。
typeof Circle.triangulationCount;  // `number^l に評価される。
Circle.prototype.triangulate;      // `undefined^v に評価される。
Circle.prototype.triangulationCount;  // これも `undefined^v に評価される。
circles[0].triangulate;            // これも。
circles[0].triangulationCount;     // これも。

// 静的~演算の~call
var triangulationPoint = Circle.triangulate(circles[0], circles[1], circles[2]);
// `triangulate^M を呼んだ回数を調べる
window.alert(Circle.triangulationCount);

3.2.6. 多重定義

`~ifc$上に定義される `正則~演算$/`静的~演算$ が,その~ifc上の同じ種類の別の(正則/静的)演算と 同じ`識別子$を持つ場合、その演算は `多重定義@ されているという。 その~ifcを実装する~obj上で,それらの演算のどれかを呼出すために多重定義された演算の識別子が利用された際に,どの演算が実際に呼出されるかは、演算に渡された引数の個数と型により決定される。 ~ifc上に複数の`旧来呼出子$が定義されている場合も、それらの旧来呼出子は多重定義されているという。 ~JS言語束縛においては `Constructor$x も多重定義され得る。 多重定義された[ 演算/旧来呼出子/構築子 ]がとり得る引数の指定には一定の制約があり、これらの制約を記述するため,`有効~多重定義~集合$の~~概念が利用される。 ◎ If a regular operation or static operation defined on an interface has an identifier that is the same as the identifier of another operation on that interface of the same kind (regular or static), then the operation is said to be overloaded. When the identifier of an overloaded operation is used to invoke one of the operations on an object that implements the interface, the number and types of the arguments passed to the operation determine which of the overloaded operations is actually invoked. If an interface has multiple legacy callers defined on it, then those legacy callers are also said to be overloaded. In the ECMAScript language binding, constructors can be overloaded too. There are some restrictions on the arguments that overloaded operations, legacy callers and constructors can be specified to take, and in order to describe these restrictions, the notion of an effective overload set is used.

`演算$/`旧来呼出子$は、複数の[ `~ifc$定義, および その`部分的~ifc定義$ ]にまたがって多重定義されては~MUST_NOT。 ◎ Operations and legacy callers MUST NOT be overloaded across interface and partial interface definitions.

例えば,次の様な `f^T, `g^T の多重定義は許容されない: ◎ For example, the overloads for both f and g are disallowed:

interface A {
  void f();
};

partial interface A {
  void f(double x);
  void g();
};

partial interface A {
  void g(DOMString x);
};

構築子の多重定義については、元々`部分的~ifc定義$上には[ `Constructor$x, `NamedConstructor$x ]`拡張属性$の出現が許容されていないので,同様の制約は~~自動的に満たされることに注意。 ◎ Note that the [Constructor] and [NamedConstructor] extended attributes are disallowed from appearing on partial interface definitions, so there is no need to also disallow overloading for constructors.

`有効~多重定義~集合@ とは、個々の `関数類@ — [ `演算$ / 構築子( `Constructor$x または `NamedConstructor$x により指定される) / `旧来呼出子$ / `呼戻~関数$ ] — に許容され得る呼出を表現するものである。

【 “関数類(引数を伴って~callし得る~IDL構成子)” という語は、簡潔に総称するためにこの訳に導入した,非公式な用語である。 】

`有効~多重定義~集合$を算出する~algoは、次に挙げる6種の~IDL構成子に対し演算する。 算出するために必要な入力は、渡される引数の個数, および `関数類$の種別に応じて,以下に示されるものになる:

◎ An effective overload set represents the allowable invocations for a particular operation, constructor (specified with [Constructor] or [NamedConstructor]), legacy caller or callback function. The algorithm to compute an effective overload set operates on one of the following six types of IDL constructs, and listed with them below are the inputs to the algorithm needed to compute the set.
正則~演算◎For regular operations
静的~演算◎For static operations
`演算$が見出された`~ifc$, および 演算の`識別子$ ◎ the interface on which the operations are to be found ◎ the identifier of the operations ◎ the number of arguments to be passed
旧来呼出子◎For legacy callers
`旧来呼出子$が見出された`~ifc$ ◎ the interface on which the legacy callers are to be found ◎ the number of arguments to be passed
構築子◎For constructors
`Constructor$x `拡張属性$が見出された`~ifc$ ◎ the interface on which the [Constructor] extended attributes are to be found ◎ the number of arguments to be passed
有名~構築子◎For named constructors
`NamedConstructor$x `拡張属性$が見出された`~ifc$, および 有名~構築子の`識別子$ ◎ the interface on which the [NamedConstructor] extended attributes are to be found ◎ the identifier of the named constructors ◎ the number of arguments to be passed
呼戻~関数◎For callback functions
`呼戻~関数$ ◎ the callback function ◎ the number of arguments to be passed

有効~多重定義~集合は、他のものと伴に,~ifc上に多重定義された`関数類$が多義性を孕んでいるかどうか決定するために利用される。 ◎ An effective overload set is used, among other things, to determine whether there are ambiguities in the overloaded operations, constructors and callers specified on an interface.

有効~多重定義~集合の各~要素は,~tuple <`ol-callable^, `ol-type-list^, `ol-optionality-list^> である:

  • %callable は、`関数類$の種別に応じて,次になる:
    • [ 正則~演算/静的~演算/旧来呼出子 ]に対しては,その いずれかの演算。
    • [ 構築子/有名~構築子 ]に対しては,その いずれかの拡張属性。
    • [ 呼戻~関数 ]に対しては,呼戻~関数~自身。
  • 型~list は、 `ol-callable^ の一連の引数にあてがわれている~IDL型の~listである。
  • 省略可否~list は,[ `省略可否 値@ と称される値 ]の~listであり、それぞれの値は[ 所与の~indexに位置する引数が[ “`必須^C”, “`省略可^C”, “`可変個^C” ]のいずれであるか ]を指示する。

各~tupleは、[ 所与の一連の型 ]による引数~値~listに許容され得る`関数類$の呼出を表現する。 `随意~引数$や[ `可変個の引数をとる$`関数類$ (すなわち,演算か構築子) ]の利用に因り、有効~多重定義~集合~内には,同じ種類の`関数類$を識別する複数の~entryが存在し得る。

◎ The elements of an effective overload set are tuples of the form <callable, type list, optionality list>. If the effective overload set is for regular operations, static operations or legacy callers, then callable is an operation; if it is for constructors or named constructors, then callable is an extended attribute; and if it is for callback functions, then callable is the callback function itself. In all cases, type list is a list of IDL types, and optionality list is a list of three possible optionality values – “required”, “optional” or “variadic” – indicating whether the argument at a given index was declared as being optional or corresponds to a variadic argument. Each tuple represents an allowable invocation of the operation, constructor, legacy caller or callback function with an argument value list of the given types. Due to the use of optional arguments and variadic operations and constructors, there may be multiple entries in an effective overload set identifying the same operation or constructor.

下の~algoが,有効~多重定義~集合を算出する方法を記述する。 必要に応じて,上述の入力~変数が利用される: ◎ The algorithm below describes how to compute an effective overload set. The following input variables are used, if they are required:

  • %A は[ 演算/有名~構築子 ]の識別子 ◎ the identifier of the operation or named constructor is A
  • %N は引数個数 ◎ the argument count is N
  • %I は~ifc ◎ the interface is I
  • %C は呼戻~関数 ◎ the callback function is C

拡張属性に対する引数が示されるときはいつでも,その拡張属性の`有名~引数~list$の引数を指しているものとする。 ◎ Whenever an argument of an extended attribute is mentioned, it is referring to an argument of the extended attribute’s named argument list.

  1. %S :← ∅ ◎ Initialize S to ∅.
  2. %F := 有効~多重定義~集合の種類に応じて,次で与えられる要素の集合: ◎ Let F be a set with elements as follows, according to the kind of effective overload set:

    正則~演算◎For regular operations

    %I 上で定義された`正則~演算$のうち,識別子が %A であるもの ◎ The elements of F are the regular operations with identifier A defined on interface I.

    静的~演算◎For static operations

    %I 上で定義された`静的~演算$のうち,識別子が %A であるもの ◎ The elements of F are the static operations with identifier A defined on interface I.

    構築子◎For constructors

    %I 上の `Constructor$x `拡張属性$ ◎ The elements of F are the [Constructor] extended attributes on interface I.

    有名~構築子◎For named constructors

    %I 上の `NamedConstructor$x `拡張属性$のうち,その`有名~引数~list$の識別子が %A であるもの ◎ The elements of F are the [NamedConstructor] extended attributes on interface I whose named argument lists’ identifiers are A.

    旧来呼出子◎For legacy callers

    %I 上で定義された `旧来呼出子$ ◎ The elements of F are the legacy callers defined on interface I.

    呼戻~関数◎For callback functions

    呼戻~関数~自身である %C (唯一つ) ◎ The single element of F is the callback function itself, C.

  3. %maxarg := %F の中の各~要素(`関数類$ )が宣言している引数~個数の最大 — ただし,[ `可変個の引数をとる$ `関数類$ ]の中の`末尾~引数$は、 1 個の引数に数える ◎ Let maxarg be the maximum number of arguments the operations, constructor extended attributes or callback functions in F are declared to take. For variadic operations and constructor extended attributes, the argument on which the ellipsis appears counts as a single argument.

    したがって `void f(long x, long... y);^c が宣言している引数~個数は 2 個と見なされる。 ◎ So void f(long x, long... y); is considered to be declared to take two arguments.

  4. %m := %maxarg と %N の最大 ◎ Let m be the maximum of maxarg and N.
  5. ~FOR %F 内の~EACH ( %X ) に対し: ◎ For each operation, extended attribute or callback function X in F:

    【 見通しを良くするため、この下位手続きの記述は,原文のものから手を加えている。 】

    1. %n := %X が宣言している引数~個数(従って %n ≤ %m ) ◎ Let n be the number of arguments X is declared to take.
    2. ~FOR 0 ≤ %i < %n なる ~EACH( 整数 %i ) に対し: %t%i := ~index %i に位置する %X の引数の型,
      %o%i := [ ~index %i に位置する %X の引数が[ 随意ならば “`省略可^C” / ~ELSE_ “`必須^C” ]]
      ◎ Let t0..n−1 be a list of types, where ti is the type of X’s argument at index i. ◎ Let o0..n−1 be a list of optionality values, where oi is “variadic” if X’s argument at index i is a final, variadic argument, “optional” if the argument is optional, and “required” otherwise. ◎ ↓↓Add to S the tuple <X, t0..n−1, o0..n−1>.
    3. ~IF %X は `可変個の引数をとる$ように宣言されている ⇒ ◎ If X is declared to be variadic, then: ◎ ↓↓Add to S the tuple <X, t0..n−2, o0..n−2>.

      ここではまだ,`末尾~引数$には触れない。 ◎ This leaves off the final, variadic argument.

      1. %o%n−1 := “`可変個^C” (上の設定を上書き) ◎ ↑
      2. ~FOR %n ≤ %i < %m なる ~EACH( 整数 %i ) に対し,~~昇順に: ◎ For every integer i, such that n ≤ i ≤ m−1:

        1. %t%i := %t%n−1,
          %o%i := “`可変個^C” ◎ Let u0..i be a list of types, where uj = tj (for j < n) and uj = tn−1 (for j ≥ n). ◎ Let p0..i be a list of optionality values, where pj = oj (for j < n) and pj = “variadic” (for j ≥ n).
        2. ~tuple <%X, (%t0 … %t%i), (%o0 … %o%i)> を %S に追加する ◎ Add to S the tuple <X, u0..i, p0..i>.
    4. ~FOR %n > %i ≥ −1 なる ~EACH( 整数 %i ) に対し,~~降順に:

      1. ~IF %i ~EQ −1 ~THEN ~tuple <%X, (), ()> を %S に追加する;
        ~BREAK
      2. ~tuple <%X, (%t0 … %t%i), (%o0 … %o%i)> を %S に追加する
      3. ~IF %o%i ~EQ “`必須^C” ~THEN ~BREAK
      ◎ Initialize i to n−1. ◎ While i ≥ 0: • If argument i of X is not optional, then break this loop. • Otherwise, add to S the tuple <X, t0..i−1, o0..i−1>. • Set i to i−1. If n > 0 and all arguments of X are optional, then add to S the tuple <X, (), ()> (where “()” represents the empty list).
  6. 有効~多重定義~集合は %S である ◎ The effective overload set is S.

次の~ifcに対し: ◎ For the following interface:

interface A {
  /* f1 */ void f(DOMString a);
  /* f2 */ void f(Node a, DOMString b, double... c);
  /* f3 */ void f();
  /* f4 */ void f(Event a, DOMString b, optional DOMString c, double... d);
};

`Node^T と `Event^T を,どの~objからも両方同時に実装できないような,別々の~ifcとするとき、[ 識別子 `f^c, 引数個数 4 ]の`正則~演算$からなる`有効~多重定義~集合$は: ◎ assuming Node and Event are two other interfaces of which no object can implement both, the effective overload set for regular operations with identifier f and argument count 4 is:

{ <f1, (DOMString), (`必須^C)>,
<f2, (Node, DOMString), (`必須^C, `必須^C)>,
<f2, (Node, DOMString, double), (`必須^C, `必須^C, `可変個^C)>,
<f2, (Node, DOMString, double, double), (`必須^C, `必須^C, `可変個^C, `可変個^C)>,
<f3, (), ()>,
<f4, (Event, DOMString), (`必須^C, `必須^C)>,
<f4, (Event, DOMString, DOMString), (`必須^C, `必須^C, `省略可^C)>,
<f4, (Event, DOMString, DOMString, double), (`必須^C, `必須^C, `省略可^C, `可変個^C)> }

2つの型が `判別可能@ であるとは、2つのうち[ `~nullable型を内包する$, または `辞書~型$である ]ものは高々1つまでであり、かつ,次の3条件のうち 少なくとも1つが成立することを意味する: ◎ Two types are distinguishable if at most one of the two includes a nullable type or is a dictionary type, and at least one of the following three conditions is true:

  1. 2つの型が(`~nullable型$の場合はその`内縁~型$が)下の表に現れ、かつ[ 対応する欄に “●” 印がある, または[ 対応する欄に英字があって,表の下に指定される追加の要件を満たす ]]: ◎ The two types (taking their inner types if they are nullable types) appear in the following table and there is a “●” mark in the corresponding entry or there is a letter in the corresponding entry and the designated additional requirement below the table is satisfied:

    `boolean$T `実数~型$ `文字列~型$ `~ifc型$ `~obj型$ `呼戻~関数$ `辞書~型$ `sequence_T^ `FrozenArray_T^ `RegExp$T `例外~型$ `~buffer~source型$
    `boolean^T `boolean^T
    実数~型 実数~型
    文字列~型 文字列~型
    ~ifc (a) (b)(b)~ifc
    `object^T `object^T
    呼戻~関数 呼戻~関数
    辞書 辞書
    `sequence<~varT>^T `sequence<~varT>^T
    `FrozenArray_T^ `FrozenArray_T^
    `RegExp^T `RegExp^T
    例外~型 例外~型
    ~buffer~source型 ~buffer~source型
    • (a) — 識別される2つの`~ifc$が,同じ`~platform~obj$に実装されることは起こり得ない(特に,2つは同じ~ifcでない), かつ 少なくとも一方は`呼戻~ifc$でない。 ◎ The two identified interfaces are not the same, it is not possible for a single platform object to implement both interfaces, and it is not the case that both are callback interfaces.

    • (b) — 2つのうち~ifc型の方は`呼戻~ifc$でない。 ◎ The interface type is not a callback interface.
  2. 一方のみが[ `共用体~型$または~nullable共用体~型 ]であって, かつ その共用体のどの`~mb型$も 他方の型と判別可能である。 ◎ One type is a union type or nullable union type, the other is neither a union type nor a nullable union type, and each member type of the first is distinguishable with the second.
  3. 両方の型が[ 共用体~型または~nullable共用体~型 ]であり, かつ 一方の各~mb型は 他方のどの~mb型とも判別可能である。 ◎ Both types are either a union type or nullable union type, and each member type of the one is distinguishable with each member type of the other.

`~promise型$は、上の表には現れていないので,他のどの型とも判別可能でないことになる。 ◎ Promise types do not appear in the above table, and as a consequence are not distinguishable with any other type.

`有効~多重定義~集合$の中に,所与の`ol-type-list^長さを持つ~entryが複数ある場合、[ それらのどの2つの~entryに対しても~index %i に位置する2つの型が`判別可能$になる ]ような,~index %i が存在し~MUST。 そのような~indexのうち,最小のものを、 【 その型~listの長さ, もしくはそれらの~entryの集合に対する 】 `判別引数~index@ と呼ぶ。 ◎ If there is more than one entry in an effective overload set that has a given type list length, then for those entries there MUST be an index i such that for each pair of entries the types at index i are distinguishable. The lowest such index is termed the distinguishing argument index for the entries of the effective overload set with the given type list length.

前の例に示された有効~多重定義~集合を考える。 `ol-type-list^長さ 2, 3, 4 の集合はそれぞれ複数の~entryを含む。 これらの`ol-type-list^長さのそれぞれに対し, `Node^T と `Event^T は`判別可能$になるので、`判別引数~index$は 0 である。 ◎ Consider the effective overload set shown in the previous example. There are multiple entries in the set with type lists 2, 3 and 4. For each of these type list lengths, the distinguishing argument index is 0, since Node and Event are distinguishable.

しかしながら,次の多重定義の利用は妥当でない: ◎ The following use of overloading however is invalid:

interface B {
  void f(long x);
  void f(double x);
};

`long$T と `double$T は判別可能でないので。 【 原文には `long$T ではなく, `DOMString$T と記されているが、それは今や `double$T と判別可能になったので,修正している。 】 ◎ since DOMString and double are not distinguishable.

加えて,所与の`ol-type-list^長さに対する `判別引数~index$ より小さい,どの~indexに対しても、[ `有効~多重定義~集合$のすべての~entryの,その~indexに位置する[ `ol-type-list^の型/`ol-optionality-list^の真偽~値 ]は,同じで~MUST ]。 ◎ In addition, for each index j, where j is less than the distinguishing argument index for a given type list length, the types at index j in all of the entries’ type lists MUST be the same and the booleans in the corresponding list indicating argument optionality MUST be the same.

次は妥当でない: ◎ The following is invalid:

interface B {
  /* f1 */ void f(DOMString w);
  /* f2 */ void f(long w, double x, Node y, Node z);
  /* f3 */ void f(double w, double x, DOMString y, Node z);
};

引数個数 4 に対する 有効~多重定義~集合は: ◎ For argument count 4, the effective overload set is:

{ <f1, (DOMString), (`必須^C)>,
<f2, (long, double, Node, Node), (`必須^C, `必須^C, `必須^C, `必須^C)>,
<f3, (double, double, DOMString, Node), (`必須^C, `必須^C, `必須^C, `必須^C)> }

であり、`ol-type-list^長さ 4 の~entryを調べると, `Node^T と `DOMString$T は`判別可能$なので、 `判別引数~index$は 2 になる。 しかしながら,これらの2つの多重定義の~index 0 に位置する引数~型は異なるので、この多重定義は妥当でない。 ◎ Looking at entries with type list length 4, the distinguishing argument index is 2, since Node and DOMString are distinguishable. However, since the arguments in these two overloads at index 0 are different, the overloading is invalid.

【 複雑な条件だが,概念的には、共用体~型を利用して,多重定義された宣言を等価な単独の宣言に統合するために必要な条件が意図されている様に見られる。 例えば,先に挙げられた例は次のように書き換え得る: 】

interface A {
             /*---f4----*/ /*-f2-*/     /*---f1----*/    /*-f3-*/
  void f(
    optional ( Event     or Node     or   DOMString ) a, /*----*/
    optional   DOMString             b, /*---------------------*/
    optional ( DOMString or double ) c, /*---------------------*/
               double...             d  /*---------------------*/
  );
};

【 しかしながら、例えば個別の宣言ごとに異なる拡張属性や特殊~演算が指定されることは,あるかもしれない — そのような場合、統合できなくなる。 この仕様の中では,そのような指定~法を明示的に禁止している箇所は見当たらない — 例えば次のように,拡張属性が多重定義の一部のみに指定されることも、無いとは言い切れない: 】

interface A {
  `NewObject$x T f(B a);
              T f(C a);
};

3.2.7. 可反復~宣言

~ifcは `可反復@ になるように宣言できる。 そのためには、`~ifc$の本体にて `可反復~宣言@ (`Iterable$g に合致)を利用する。 ◎ An interface can be declared to be iterable by using an iterable declaration (matching Iterable) in the body of the interface.

iterable<`value-type^i>;
iterable<`key-type^i, `value-type^i>;

可反復として宣言された~ifcを実装している~objは、値の連列を得るために反復し得るようになる。 ◎ Objects implementing an interface that is declared to be iterable support being iterated over to obtain a sequence of values.

~JS言語束縛においては、可反復な~ifcは、その`~ifc原型~obj$上に,[ `entries^l, `forEach^l, `keys^l, `values^l, `iterator_symbol^ ]~propを持つことになる。 ◎ In the ECMAScript language binding, an interface that is iterable will have “entries”, “forEach”, “keys”, “values” and @@iterator properties on its interface prototype object.

~parameterとして所与の型の個数が:

  • 1 個の場合、~ifcは,その型の値たちを提供する `値~反復子@ を持つことになる。
  • 2 個の場合、~ifcは,[ ~key, 値 ]からなる~pairたちを提供する `~pair反復子@ を持つことになる。 ここで、~pairの~keyは,最初の型の値をとり、~pairの値は,二番目の型の値をとる。
◎ If a single type parameter is given, then the interface has a value iterator and provides values of the specified type. If two type parameters are given, then the interface has a pair iterator and provides value pairs, where the first value is a key and the second is the value associated with the key.

`値~反復子$を宣言できる~ifcは、`有index~propを~supportする$, かつ 名前 `length^l の`整数~型$の`属性$を持つもののみで~MUST。 `値~反復子$の値~型は、`有index~prop取得子$が返す型と同じで~MUST。 `値~反復子$は暗黙的に,当の~objの有index~prop上を反復するように定義される。 ◎ A value iterator MUST only be declared on an interface that supports indexed properties and has an integer-typed attribute named “length”. The value-type of the value iterator MUST be the same as the type returned by the indexed property getter. A value iterator is implicitly defined to iterate over the object’s indexed properties.

`~pair反復子$は、`有index~propを~supportする$~ifc上に宣言されては~MUST_NOT。 `~pair反復子$を伴う`~ifc$においては、付随する注釈文にて[ 何が `反復される値~pair@ の~listを成すのか ]が定義され~MUST。 ◎ A pair iterator MUST NOT be declared on an interface that supports indexed properties. Prose accompanying an interface with a pair iterator MUST define what the list of value pairs to iterate over is.

`値~反復子$に対し生成される~JS `forEach^c ~methは、 `Array.prototype.forEach^c が行うように,その呼戻子を呼出す。 `~pair反復子$に対する `forEach^c ~methは、 `Map.prototype.forEach^c が行うように,その呼戻子を呼出す。 ◎ The ECMAScript forEach method that is generated for a value iterator invokes its callback like Array.prototype.forEach does, and the forEach method for a pair iterator invokes its callback like Map.prototype.forEach does.

現在,`値~反復子$は`有index~propを~supportする$~ifcのみに許容されているので、 `forEach^c ~methを配列のように利用することにも~~意味がある。 `値~反復子$は、次のものにも必要かもしれない: (a) `有index~propを~support$しない~ifc上, あるいは (b) 呼戻子を,代わりに `Set.protoype.forEach^c のように呼出す(ここで~keyは,値と同じ)ような `forEach^c ~methに対して。 そのような `forEach^c ~methを必要とする API を再~作成している策定者は、 public-script-coord@w3.org 宛まで要請されたし。 ◎ Since value iterators are currently allowed only on interfaces that support indexed properties, it makes sense to use an Array-like forEach method. There may be a need for value iterators (a) on interfaces that do not support indexed properties, or (b) with a forEach method that instead invokes its callback like Set.protoype.forEach (where the key is the same as the value). If you’re creating an API that needs such a forEach method, please send a request to public-script-coord@w3.org.

`配列~反復子~obj$は,このように働く。 `有index~propを~supportする$ ~ifcに対しては、[ `entries^l / `keys^l / `values^l / `iterator_symbol^ ]から返される反復子~objは,実際の`配列~反復子~obj$である。 ◎ This is how array iterator objects work. For interfaces that support indexed properties, the iterator objects returned by “entries”, “keys”, “values” and @@iterator are actual array iterator objects.

可反復~宣言を伴う~ifcの[ `広義~帰結~ifc$, `被継承~ifc$ ]は、名前[ `entries^l / `forEach^l / `keys^l / `values^l ]の`~ifc~mb$を持っては~MUST_NOT。 ◎ Interfaces with iterable declarations MUST NOT have any interface members named “entries”, “forEach”, “keys” or “values”, or have any inherited or consequential interfaces that have interface members with these names.

次の~ifcを考える。 `SessionManager^T は、一連の `Session^T ~objに~accessできるようにする: ◎ Consider the following interface SessionManager, which allows access to a number of Session objects:

interface SessionManager {
  Session getSessionForUser(DOMString username);
  readonly attribute unsigned long sessionCount;

  iterable<Session>;
};

interface Session {
  readonly attribute DOMString username;
  // ...
};

反復子の挙動は、次に従うように定義できる: ◎ The behavior of the iterator could be defined like so:

`反復される値$は、[ `username^M の昇順で整列された, `SessionManager^T 上の一連の `Session^T ~obj ]である。 ◎ The values to iterate over are the open Session objects on the SessionManager sorted by username.

~JS言語束縛においては、 `SessionManager^T `~ifc$に対する`~ifc原型~obj$は、[ 被呼出時に[[ 次の反復値を返す `next^c ~meth ]を持つ反復子~obj ]を返すような,関数 ]である `values^c ~meth を持つことになる。 それは、[ 一連の `Session^T ~objからなる~list ]の[ 各~index / 各 ( ~index, `Session^T ~obj ) ~pair ]を反復する[ `values^c / `entries^c ]~methを持つ。 それは、 `SessionManager^T を `for..of^c ~loopの中でも利用できるようする, `iterator_symbol^ ~methも持つ: ◎ In the ECMAScript language binding, the interface prototype object for the SessionManager interface has a values method that is a function, which, when invoked, returns an iterator object that itself has a next method that returns the next value to be iterated over. It has values and entries methods that iterate over the indexes of the list of session objects and [index, session object] pairs, respectively. It also has a @@iterator method that allows a SessionManager to be used in a for..of loop:

// `SessionManager^T の~instanceを取得する。
// 2人の利用者 `anna^l と `brian^l に対する session があるとする。
var sm = getSessionManager();

typeof SessionManager.prototype.values;
                         // 
var it = sm.values();    // `values()^c は反復子~objを返す
String(it);              // `[object SessionManager Iterator]^l に評価される
typeof it.next;          // 

// この~loopは `anna^l を alert した後 `brian^l を alert することになる。
for (;;) {
  let result = it.next();
  if (result.done) {
    break;
  }
  let session = result.value;
  window.alert(session.username);
}

// この~loopも `anna^l を alert した後 `brian^l を alert することになる。
for (let session of sm) {
  window.alert(session.username);
}

`可反復~宣言$を伴う~ifcの[ `広義~帰結~ifc$ / `被継承~ifc$ ]に,[ 別の`可反復~宣言$, `~maplike 宣言$, `~setlike 宣言$ ]が宣言されては~MUST_NOT。 ◎ An interface MUST NOT have more than one iterable declaration. The inherited and consequential interfaces of an interface with an iterable declaration MUST NOT also have an iterable declaration. An interface with an iterable declaration and its inherited and consequential interfaces MUST NOT have a maplike declaration or setlike declaration.

`可反復~宣言$には、次の拡張属性を適用し得る: `Exposed$x, `SecureContext$x 。 ◎ The following extended attributes are applicable to iterable declarations: [Exposed], [SecureContext].

Iterable OptionalType

3.2.8. ~maplike 宣言

~ifcは `~maplike@ になるように宣言できる。 そのためには、`~ifc$の本体にて `~maplike 宣言@ ( `ReadWriteMaplike$g / `readonly^sym `MaplikeRest$g いずれかに合致)を利用する。 ◎ An interface can be declared to be maplike by using a maplike declaration (matching ReadWriteMaplike or "readonly" MaplikeRest) in the body of the interface.

readonly maplike<`key-type^i, `value-type^i>;
maplike<`key-type^i, `value-type^i>;

~maplikeになるように宣言された~ifcを実装する~objは、その一連の[ `~map~entry@ と呼ばれる~key-value ]からなる,順序付けられた~listを表現する。 ~keyおよび~valueに利用される型は、~maplike 宣言の山括弧の中で与えられる。 それらの~keyは一意になることが要求される。 ◎ Objects implementing an interface that is declared to be maplike represent an ordered list of key–value pairs known as its map entries. The types used for the keys and values are given in the angle brackets of the maplike declaration. Keys are required to be unique.

`~maplike$ ~ifcを実装している~objの`~map~entry$の~listは、~objの作成~時には空である。 ~ifcに付随している注釈文は、~objの一連の`~map~entry$がどのように変化するかを述べ得る。 ◎ The map entries of an object implementing a maplike interface is empty at the of the object’s creation. Prose accompanying the interface can describe how the map entries of an object change.

~maplike~ifcは、一連の~map~entryを照会するための,言語束縛に適切な API を~supportする。 `readonly^c ~keywordが利用されなかった場合†、~map~entryを改変するための API も~supportする。 【† 以下, “可書~maplike” とも記される】 ◎ Maplike interfaces support an API for querying the map entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the map entries.

~JS言語束縛においては、一連の~map~entryとやりとりするための API は, ~JSにて可用な `Map^t ~objに類似する。 `readonly^c ~keywordが利用された場合、それは[ `entries^l, `forEach^l, `get^l, `has^l, `keys^l, `values^l, `iterator_symbol^ ]~meth, および `size^l 取得子を含む。 可書~maplikeに対しては、更に[ `clear^l, `delete^l, `set^l ]~methも含む。 ◎ In the ECMAScript language binding, the API for interacting with the map entries is similar to that available on ECMAScript Map objects. If the readonly keyword is used, this includes “entries”, “forEach”, “get”, “has”, “keys”, “values”, @@iterator methods and a “size” getter. For read–write maplikes, it also includes “clear”, “delete” and “set” methods.

~maplike~ifcの[ `広義~帰結~ifc$, `被継承~ifc$ ]は、名前が[ `entries^l/`forEach^l/`get^l/`has^l/`keys^l/`size^l/`values^l ]であるような `~ifc~mb$を持っては~MUST_NOT。 可書~maplike~ifcの[ `広義~帰結~ifc$, `被継承~ifc$ ]は、名前が[ `clear^l/`delete^l/`set^l ]であるような `属性$や`定数$も持っては~MUST_NOT。 ◎ Maplike interfaces MUST NOT have any interface members named “entries”, “forEach”, “get”, “has”, “keys”, “size”, or “values”, or have any inherited or consequential interfaces that have interface members with these names. Read–write maplike interfaces MUST NOT have any attributes or constants named “clear”, “delete”, or “set”, or have any inherited or consequential interfaces that have attributes or constants with these names.

名前[ `clear^l/`delete^l/`set^l ]の演算は,可書~maplike~ifc上にも許容され、その場合,~JS言語束縛においては,その~methの既定の実装は `~ifc原型~obj$に追加されなくなる。 これにより、これらの演算の既定の挙動を上書きできるようになる。 ◎ Operations named “clear”, “delete”, or “set” are allowed on read–write maplike interfaces and will prevent the default implementation of these methods being added to the interface prototype object in the ECMAScript language binding. This allows the default behavior of these operations to be overridden.

~maplike~ifcの[ `広義~帰結~ifc$ / `被継承~ifc$ ]に,[ `可反復~宣言$, 別の`~maplike 宣言$, `~setlike 宣言$ ]が宣言されては~MUST_NOT。 ◎ An interface MUST NOT have more than one maplike declaration. The inherited and consequential interfaces of a maplike interface MUST NOT also have a maplike declaration. A maplike interface and its inherited and consequential interfaces MUST NOT have an iterable declaration or setlike declaration.

ReadOnlyMember ReadOnlyMemberRest ReadWriteMaplike MaplikeRest

`~maplike 宣言$に適用し得る`拡張属性$は、この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to maplike declarations.

例を追加する。 ◎ Add example.

3.2.9. ~setlike 宣言

~ifcは `~setlike@ になるように宣言できる。 そのためには、`~ifc$の本体にて `~setlike 宣言@ ( `ReadWriteSetlike$g / `readonly^sym `SetlikeRest$g いずれかに合致)を利用する。 ◎ An interface can be declared to be setlike by using a setlike declaration (matching ReadWriteSetlike or "readonly" SetlikeRest) in the body of the interface.

readonly setlike<`type^i>;
setlike<`type^i>;

~setlikeになるように宣言された~ifcを実装する~objは、その一連の[ `~set~entry@ と呼ばれる~value ]からなる,順序付けられた~listを表現する。 ~valueに利用される型は、~setlike 宣言の山括弧の中で与えられる。 それらの~valueは一意になることが要求される。 ◎ Objects implementing an interface that is declared to be setlike represent an ordered list of values known as its set entries. The type of the values is given in the angle brackets of the setlike declaration. Values are required to be unique.

`~setlike$ ~ifcを実装している~objの`~set~entry$の~listは、~objの作成~時には空である。 ~ifcに付随している注釈文は、~objの一連の`~set~entry$がどのように変化するかを述べ得る。 ◎ The set entries of an object implementing a setlike interface is empty at the of the object’s creation. Prose accompanying the interface can describe how the set entries of an object change.

~setlike~ifcは、一連の~set~entryを照会するための,言語束縛に適切な API を~supportする。 `readonly^c ~keywordが利用されなかった場合†、~set~entryを改変するための API も~supportする。 【† 以下, “可書~setlike” とも記される】 ◎ Setlike interfaces support an API for querying the set entries appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying the set entries.

~JS言語束縛においては、一連の~set~entryとやりとりするための API は, ~JSにて可用な `Set^t ~objに類似する。 `readonly^c ~keywordが利用された場合、それは[ `entries^l, `forEach^l, `has^l, `keys^l, `values^l, `iterator_symbol^ ]~meth, および `size^l 取得子を含む。 可書~setlikeに対しては、更に[ `add^l, `clear^l, `delete^l ]~methも含む。 ◎ In the ECMAScript language binding, the API for interacting with the set entries is similar to that available on ECMAScript Set objects. If the readonly keyword is used, this includes “entries”, “forEach”, “has”, “keys”, “values”, @@iterator methods and a “size” getter. For read–write setlikes, it also includes “add”, “clear”, and “delete” methods.

~setlike~ifcの[ `広義~帰結~ifc$, `被継承~ifc$ ]は、名前が[ `entries^l/`forEach^l/`has^l/`keys^l/`size^l/`values^l ]であるような `~ifc~mb$を持っては~MUST_NOT。 可書~setlike~ifcの[ `広義~帰結~ifc$, `被継承~ifc$ ]は、名前が[ `add^l/`clear^l/`delete^l ]であるような `属性$や`定数$も持っては~MUST_NOT。 ◎ Setlike interfaces MUST NOT have any interface members named “entries”, “forEach”, “has”, “keys”, “size”, or “values”, or have any inherited or consequential interfaces that have interface members with these names.. Read–write setlike interfaces MUST NOT have any attributes or constants named “add”, “clear”, or “delete”, or have any inherited or consequential interfaces that have attributes or constants with these names.

名前[ `add^l/`clear^l/`delete^l ]の演算は,可書~setlike~ifc上にも許容され、その場合,~JS言語束縛においては,その~methの既定の実装は `~ifc原型~obj$に追加されなくなる。 これにより、これらの演算の既定の挙動を上書きできるようになる。 ◎ Operations named “add”, “clear”, or “delete” are allowed on read–write setlike interfaces and will prevent the default implementation of these methods being added to the interface prototype object in the ECMAScript language binding. This allows the default behavior of these operations to be overridden.

~setlike~ifcの[ `広義~帰結~ifc$ / `被継承~ifc$ ]に,[ `可反復~宣言$, `~maplike 宣言$, 別の`~setlike 宣言$ ]が宣言されては~MUST_NOT。 ◎ An interface MUST NOT have more than one setlike declaration. The inherited and consequential interfaces of a setlike interface MUST NOT also have a setlike declaration. A setlike interface and its inherited and consequential interfaces MUST NOT have an iterable declaration or maplike declaration.

ReadOnlyMember ReadOnlyMemberRest ReadWriteSetlike SetlikeRest

`~setlike 宣言$に適用し得る`拡張属性$は、この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to setlike declarations.

例を追加する。 ◎ Add example.

3.3. 辞書

`辞書@ は、固定的かつ順序付けられた~keyの集合による, ~key-valueの連想配列~data型を定義するために利用される,`定義$( `Dictionary$g に合致)である。 各~pairを `辞書~mb@ と呼ぶ。 その~keyは文字列であり,その値は定義の中で指定される個々の型に属する。 ◎ A dictionary is a definition (matching Dictionary) used to define an associative array data type with a fixed, ordered set of key–value pairs, termed dictionary members, where keys are strings and values are of a particular type specified in the definition.

dictionary `identifier^i {
  `dictionary-members…^i
};

辞書は常に値渡しである。 辞書が何らかの種類の~objで表現される言語束縛においても、`~platform~obj$に辞書が渡された際に,その辞書への参照が~objに保有されることはない。 同様に,~platform~objから返されるどの辞書も複製であり、それに対する改変は~platform~objからは見えないことになる。 ◎ Dictionaries are always passed by value. In language bindings where a dictionary is represented by an object of some kind, passing a dictionary to a platform object will not result in a reference to the dictionary being kept by that object. Similarly, any dictionary returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

辞書は 別の辞書を 継承- するように定義し得る。 辞書の識別子に~colonと`識別子$が後続するとき、後者の識別子が,継承される辞書を識別する。 この識別子は辞書を識別するもので~MUST。 ◎ A dictionary can be defined to inherit from another dictionary. If the identifier of the dictionary is followed by a colon and a identifier, then that identifier identifies the inherited dictionary. The identifier MUST identify a dictionary.

辞書は、その継承階層が循環するように宣言されては~MUST_NOT。 すなわち、辞書 %A は自身を継承することも, %A を継承する別の辞書 %B を継承することもできない,等々。 ◎ A dictionary MUST NOT be declared such that its inheritance hierarchy has a cycle. That is, a dictionary A cannot inherit from itself, nor can it inherit from another dictionary B that inherits from A, and so on.

dictionary `Base^mk {
  `dictionary-members…^i
};

dictionary `Derived^i : `Base^mk {
  `dictionary-members…^i
};

所与の辞書~型 %D の `被継承~辞書@ とは、 %D が直接的にまたは間接的に継承するすべての辞書の集合である。 %D が他の辞書を`辞書継承^しない場合、その集合は空である。 そうでない場合、その集合は %D が`辞書継承^する~ifc %E と %E の`被継承~辞書$すべてを含む。 ◎ The inherited dictionaries of a given dictionary D is the set of all dictionaries that D inherits from, directly or indirectly. If D does not inherit from another dictionary, then the set is empty. Otherwise, the set includes the dictionary E that D inherits from and all of E’s inherited dictionaries.

型 %D の辞書~値 %d は、 %D 上および %D の`被継承~辞書$上で定義される辞書~mbに対応する~key-valueを持ち得る。 %d 上における,各~辞書~mbの存在tは、それが %D において`必須~辞書~mb$であると指定されていない限り,随意である。 %d 上に指定されているならば,その辞書~mbは `在する@ ( present )といい、そうでない場合は `不在$ という。 辞書~mbは,随意で 既定~値 も持ち得る。 それは、 %d 上にその~mb値が指定されずに %d が`~platform~obj$に渡された際に,辞書~mbに利用される値と見なされる。 既定~値を伴う辞書~mbは常に在するものと見なされる。 ◎ A dictionary value of type D can have key–value pairs corresponding to the dictionary members defined on D and on any of D’s inherited dictionaries. On a given dictionary value, the presence of each dictionary member is optional, unless that member is specified as required. When specified in the dictionary value, a dictionary member is said to be present, otherwise it is not present. Dictionary members can also optionally have a default value, which is the value to use for the dictionary member when passing a value to a platform object that does not have a specified value. Dictionary members with default values are always considered to be present.

演算~引数の`既定~値$と同様に、 `boolean$T 型の辞書~mbに対しては、既定~値として `true^V を利用しないことを強く勧める。 さもなければ、 `undefined^v に既定の変換(すなわち, `false^V )が利用されると期待する作者たちを惑わすことになるので。 ◎ As with operation argument default values, is strongly suggested not to use of true as the default value for boolean-typed dictionary members, as this can be confusing for authors who might otherwise expect the default conversion of undefined to be used (i.e., false).

各`辞書~mb$( `DictionaryMember$g に合致)は、型( `Type$g に合致)および, 後続の( `identifier$g ~tokで与えられる)`識別子$により指定され、その識別子が~key-valueの~key名になる。 `Type$g が `?^c 付きの`識別子$である場合、その識別子は[ ~ifc, `列挙$, `呼戻~関数$, `~typedef$ ]のいずれかに識別され~MUST。 辞書~mb型が `?^c 付きでない識別子である場合、その識別子は,それらの定義, または`辞書$に識別され~MUST。 ◎ Each dictionary member (matching DictionaryMember) is specified as a type (matching Type) followed by an identifier (given by an identifier token following the type). The identifier is the key name of the key–value pair. If the Type is an identifier followed by ?, then the identifier MUST identify an interface, enumeration, callback function or typedef. If the dictionary member type is an identifier not followed by ?, then the identifier MUST identify any one of those definitions or a dictionary.

dictionary `identifier^i {
  `type^i `identifier^i;
};

識別子に `U+003D EQUALS SIGN ("=")^char と値( `DefaultValue$g に合致)が後続している場合、それが辞書~mbの `辞書既定値^ を与える。 ◎ If the identifier is followed by a U+003D EQUALS SIGN ("=") and a value (matching DefaultValue), then that gives the dictionary member its default value.

dictionary `identifier^i {
  `type^i `identifier^i = `value^i;
};

`辞書既定値^に[ `定数~tok$ / `string$g ~tok / 2 個の~tok並び `[]^c ]が利用された場合、 `演算$の引数の`既定~値$ のときと同じ仕方で解釈される。 ◎ When a boolean literal token (true or false), the null token, an integer token, a float token, one of the three special floating point literal values (Infinity, -Infinity or NaN), a string token or the two token sequence [] used as the default value, it is interpreted in the same way as for an operation’s optional argument default value.

`辞書~mb$の型が`列挙$である場合、その`辞書既定値^に指定される値は,その`列挙~値$のいずれかで~MUST。 ◎ If the type of the dictionary member is an enumeration, then its default value if specified MUST be one of the enumeration’s values.

辞書~mbの型の前に ~keyword `required^c が置かれた場合、その~mbは `必須~辞書~mb@ と見なされ,辞書~上に`在する$ことが要求される。 `必須~辞書~mb$は、`既定~値$を持っては~MUST_NOT。 ◎ If the type of the dictionary member is preceded by the required keyword, the member is considered a required dictionary member and must be present on the dictionary. A required dictionary member MUST NOT have a default value.

dictionary `identifier^i {
  required `type^i `identifier^i;
};

辞書~mbの型は,その辞書を 内包 しては~MUST_NOT。 次のいずれかを満たす型 %T は、辞書~型 %D を内包するものとされる: ◎ The type of a dictionary member MUST NOT include the dictionary it appears on. A type includes a dictionary D if at least one of the following is true:

  • %T は %D である ◎ the type is D
  • %T は %D を`辞書継承^している辞書である ◎ the type is a dictionary that inherits from D
  • %T は`~nullable型$であり,その`内縁~型$は %D を内包している ◎ the type is a nullable type whose inner type includes D
  • %T は[ `連列~型$, または`凍結~配列~型$ ]であり,その要素~型は %D を内包している ◎ the type is a sequence type or frozen array whose element type includes D
  • %T は`共用体~型$であり,そのいずれかの`~mb型$は %D を内包している ◎ the type is a union type, one of whose member types includes D
  • %T は辞書であり,そのいずれかの[ 自前の, または 継承している ]~mbの型は %D を内包している ◎ the type is a dictionary, one of whose members or inherited members has a type that includes D

~ifcと同様に、辞書のための~IDLは `部分的~辞書~定義@ ( `partial^sym `Dictionary$g に合致)を利用して複数の部分に分割できる。 部分的~辞書~定義の`識別子$は、当の辞書~定義の識別子と同じで~MUST。 それぞれの部分的~辞書~定義に現れるすべての~mbは、辞書~自身の~mbと見なされる。 ◎ As with interfaces, the IDL for dictionaries can be split into multiple parts by using partial dictionary definitions (matching "partial" Dictionary). The identifier of a partial dictionary definition MUST be the same as the identifier of a dictionary definition. All of the members that appear on each of the partial dictionary definitions are considered to be members of the dictionary itself.

dictionary `SomeDictionary^mk {
  `dictionary-members…^i
};

partial dictionary `SomeDictionary^mk {
  `dictionary-members…^i
};

部分的~ifc定義と同様に、部分的~辞書~定義の目的は、辞書の定義を 文書の複数の節, ときには複数の文書に分離できるようにして,仕様の編集を補助する所にある。 ◎ As with partial interface definitions, partial dictionary definitions are intended for use as a specification editorial aide, allowing the definition of an interface to be separated over more than one section of the document, and sometimes multiple documents.

所与の辞書~上の`辞書~mb$は、継承された辞書~mbが 非継承~mbより前に位置するように順序付けられる。 1つの辞書~定義~上の(部分的~辞書~定義もすべて含めた)すべての辞書~mbは、それらの識別子を構成する Unicode 符号位置により,辞書式に順序付けられる。 ◎ The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered before non-inherited members, and the dictionary members on the one dictionary definition (including any partial dictionary definitions) are ordered lexicographically by the Unicode codepoints that comprise their identifiers.

例えば,次の定義では: ◎ For example, with the following definitions:

dictionary B : A {
  long b;
  long a;
};

dictionary A {
  long c;
  long g;
};

dictionary C : B {
  long e;
  long f;
};

partial dictionary A {
  long h;
  long d;
};

型 `C^T の辞書~値の `辞書~mb$の順序は[ `c^M, `d^M, `g^M, `h^M, `a^M, `b^M, `e^M, `f^M ]になる。 ◎ the order of the dictionary members of a dictionary value of type C is c, d, g, h, a, b, e, f.

辞書の~mbは順序付けられることが要求される。 一部の言語束縛においては、~platform~objに辞書~値を渡した際に観測される挙動が,辞書~mbを取りに行く順序に依存するので。 例えば,次の追加の~ifc: ◎ Dictionaries are required to have their members ordered because in some language bindings the behavior observed when passing a dictionary value to a platform object depends on the order the dictionary members are fetched. For example, consider the following additional interface:

interface Something {
  void f(A a);
};

および,次の~JS~codeを考えるとき: ◎ and this ECMAScript code:

var something = getSomething();  // `Something^T の~instanceを取得する。
var x = 0;

var dict = { };
Object.defineProperty(dict, "d", { get: function() { return ++x; } });
Object.defineProperty(dict, "c", { get: function() { return ++x; } });

something.f(dict);

辞書~mbを取りに行く順序が、それらがとることになる値を決定する。 `A^T における順序は, `c^M の次が `d^M と定義されるので、 `c^M に対する値は 1 になり, `d^M に対する値は 2 になる。 ◎ The order that the dictionary members are fetched in determines what values they will be taken to have. Since the order for A is defined to be c then d, the value for c will be 1 and the value for d will be 2.

辞書~mbの識別子は、その辞書~上, またはその辞書の`被継承~辞書$上で定義される,別の辞書~mbの識別子と同じになっては~MUST_NOT。 ◎ The identifier of a dictionary member MUST NOT be the same as that of another dictionary member defined on the dictionary or on that dictionary’s inherited dictionaries.

辞書は[ `属性$/`定数$ ]の型に利用されては~MUST_NOT。 ◎ Dictionaries MUST NOT be used as the type of an attribute or constant.

`辞書$には、次の拡張属性を適用し得る: `Constructor$x, `Exposed$x, `SecureContext$x 。 ◎ The following extended attributes are applicable to dictionaries: [Constructor], [Exposed], [SecureContext],

辞書~mbには、次の拡張属性を適用し得る: `Clamp$x, `EnforceRange$x 。 ◎ The following extended attributes are applicable to dictionary members: [Clamp], [EnforceRange].

--Partial --PartialDefinition -Dictionary -DictionaryMembers -DictionaryMember -PartialDictionary -Default --DefaultValue --Inheritance

辞書~型の利用の1つは、`演算$に対し、 呼出し~codeの所で指定される順序に制約を課すことなく,随意~引数をいくつでも与えられるようにすることである。 例えば,次の`~IDL片$を考える: ◎ One use of dictionary types is to allow a number of optional arguments to an operation without being constrained as to the order they are specified at the call site. For example, consider the following IDL fragment:

[Constructor]
interface Point {
  attribute double x;
  attribute double y;
};

dictionary PaintOptions {
  DOMString? fillPattern = "black";
  DOMString? strokePattern = null;
  Point position;
};

interface GraphicsContext {
  void drawRectangle(double width, double height, optional PaintOptions options);
};

この~IDLの~JS実装においては、随意の `PaintOptions^T 辞書 により, `Object^t を渡すことができる: ◎ In an ECMAScript implementation of the IDL, an Object can be passed in for the optional PaintOptions dictionary:

// `GraphicsContext^T の~instanceを取得する。
var ctx = getGraphicsContext();

// 矩形を描く。
ctx.drawRectangle(300, 200, { fillPattern: "red", position: new Point(10, 10) });

`fillPattern^M と `strokePattern^M のいずれにも`辞書既定値^が与えられているので、 `drawRectangle^M の定義においては,それらが省略された場合でも所与の既定~値を持つと見なすことができ、それらが`不在$の場合に取扱う方法についての明示的な言及が不要になる。 ◎ Both fillPattern and strokePattern are given default values, so if they are omitted, the definition of drawRectangle can assume that they have the given default values and not include explicit wording to handle their non-presence.

3.4. 例外

`例外@ とは、~errorを表現する~objの型であり,実装により[ 投出される, または first ~class値として扱われる ]ものである。 Web IDL では,例外を定義することは許容されないが、代わりに 仕様が参照し,その演算, 属性, 等々の定義にて投出できるような,いくつもの定義済みの例外がある。 例外は、次のものを持つ:

`~error名@
`DOMString$T による,例外が表現する~errorの型
`~message@(随意)
~errorの詳細を人が読める~~形で提供する,~UAにより定義される値
◎ An exception is a type of object that represents an error and which can be thrown or treated as a first class value by implementations. Web IDL does not allow exceptions to be defined, but instead has a number of pre-defined exceptions that specifications can reference and throw in their definition of operations, attributes, and so on. Exceptions have an error name, a DOMString, which is the type of error the exception represents, and a message, which is an optional, user agent-defined value that provides human readable details of the error.

仕様にて投出するために可用な例外には2つの種類がある。 まず、次のいずれかの名前として識別される `単純例外@ : ◎ There are two kinds of exceptions available to be thrown from specifications. The first is a simple exception, which is identified by one of the following names:

  • `Error$T
  • `EvalError^T
  • `RangeError^T
  • `ReferenceError^T
  • `TypeError^T
  • `URIError^T

これらは、 ~JS~error~obj( `ECMA-262$r, 19.5 節)に対応する( `SyntaxError^t は除く — それは~JS構文解析器でのみ利用されるので,~~意図的に除かれている)。 各 `単純例外$の意味は、~JS仕様における対応する `Error^t ~objに合致する。 ◎ These correspond to all of the ECMAScript error objects ([ECMA-262], section 19.5) (apart from SyntaxError, which is deliberately omitted as it is for use only by the ECMAScript parser). The meaning of each simple exception matches its corresponding Error object in the ECMAScript specification.

もう一種の例外は `DOMException@ である — それは,歴史的に DOM にて定義された例外との互換性をとるための例外であり、名前と整数~code(後者は随意)を,~encapsulateする。 ◎ The second kind of exception is a DOMException, which is an exception that encapsulates a name and an optional integer code, for compatibility with historically defined exceptions in the DOM.

`単純例外$に対しては、その例外の名前が,そのまま`~error名$になる。 `DOMException$に対しては、`~error名$は,後に示す`~error名~一覧$に挙げられている いずれかの名前で~MUST。 その一覧には、その~error名に対する`DOMException$の整数~codeも(もし在れば)指示される。 ◎ For simple exceptions, the error name is the name of the exception. For a DOMException, the error name MUST be one of the names listed in the error names table below. The table also indicates the DOMException's integer code for that error name, if it has one.

例外~objを指すために利用し得る,2種の`型$がある: すべての例外が含まれる `Error$T, および DOMException ~objのみを含む `DOMException$T 。 これにより、`演算$の`返値型$を `DOMException$ に宣言したり,`属性$の型を `Error$T 型にすることも可能になる。 ◎ There are two types that can be used to refer to exception objects: Error, which encompasses all exceptions, and DOMException which includes just DOMException objects. This allows for example an operation to be declared to have a DOMException return type or an attribute to be of type Error.

例外は、その`~error名$を提供して `作成する@ こともできる。 例外は、それを`作成する$ために要求される詳細を提供して `投出する@ こともできる。 ◎ Exceptions can be created by providing its error name. Exceptions can also be thrown, by providing the same details required to create one.

例外を作成したり, 作成した例外を投出した結果の挙動は、言語束縛~特有になる。 ◎ The resulting behavior from creating and throwing an exception is language binding-specific.

~JS言語束縛の場合にどうなるかについては、 `es-creating-throwing-exceptions$secに。 ◎ See section 4.13 below for details on what creating and throwing an exception entails in the ECMAScript language binding.

例外を作成して投出する言い回しの用例をここに示す。 名前 `TypeError^T の新たな `単純例外$を投出するときは†: ◎ Here is are some examples of wording to use to create and throw exceptions. To throw a new simple exception named TypeError:

`TypeError^t を`投出$。 ◎ Throw a TypeError.

`~error名$ `IndexSizeError^T の 新たな `DOMException$を投出するときは†: ◎ To throw a new DOMException with error name IndexSizeError:

`IndexSizeError^t を`投出$。 ◎ Throw an IndexSizeError.

【† この訳では、~algoの中では,記号 ~THROW を利用して記される。 】

`~error名$ `SyntaxError^T の新たな `DOMException$を作成するときは: ◎ To create a new DOMException with error name SyntaxError:

%object := 新たに`作成-$された `SyntaxError^t ◎ Let object be a newly created SyntaxError.

3.4.1. ~error名

下の `~error名~一覧@ は、 `DOMException$ に許容されるすべての~error名, 説明, および 旧来の code 名とその値の一覧である。 ◎ The error names table below lists all the allowed error names for DOMExceptions, a description, and legacy code values.

ここに挙げられていない~error名があれば、この仕様の冒頭に指示したように, ~bugを申請されるよう願う。 間もなく解消に向けて取り組まれることになる。 Thanks! ◎ If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks!

名前◎Name 説明◎Description 旧来の code 名(数値) ◎ Legacy code name and value
`IndexSizeError@err

index は許容されている範囲に入っていない。 ◎ The index is not in the allowed range.

`INDEX_SIZE_ERR^c (1)
`HierarchyRequestError@err

演算から不正な~node木が得られることになる。 ◎ The operation would yield an incorrect node tree.

`HIERARCHY_REQUEST_ERR^c (3)
`WrongDocumentError@err

~objが属している文書は誤っている。 ◎ The object is in the wrong document.

`WRONG_DOCUMENT_ERR^c (4)
`InvalidCharacterError@err

文字列に妥当でない文字が含まれている。 ◎ The string contains invalid characters.

`INVALID_CHARACTER_ERR^c (5)
`NoModificationAllowedError@err

~objは改変できない。 ◎ The object can not be modified.

`NO_MODIFICATION_ALLOWED_ERR^c (7)
`NotFoundError@err

~objは見つからなかった。 ◎ The object can not be found here.

`NOT_FOUND_ERR^c (8)
`NotSupportedError@err

演算は~supportされていない。 ◎ The operation is not supported.

`NOT_SUPPORTED_ERR^c (9)
`InUseAttributeError@err

属性は使用中にある。 ◎ The attribute is in use.

`INUSE_ATTRIBUTE_ERR^c (10)
`InvalidStateError@err

~objは不正な状態にある。 ◎ The object is in an invalid state.

`INVALID_STATE_ERR^c (11)
`SyntaxError@err

文字列は期待される~patternに合致していない。 ◎ The string did not match the expected pattern.

`SYNTAX_ERR^c (12)
`InvalidModificationError@err

~objはこの仕方では改変できない。 ◎ The object can not be modified in this way.

`INVALID_MODIFICATION_ERR^c (13)
`NamespaceError@err

演算は Namespaces in XML において許容されない。 `XMLNS$r ◎ The operation is not allowed by Namespaces in XML. [XMLNS]

`NAMESPACE_ERR^c (14)
`InvalidAccessError@err

~objは演算または引数を~supportしない。 ◎ The object does not support the operation or argument.

`INVALID_ACCESS_ERR^c (15)
`SecurityError@err

演算は保安的でない。 ◎ The operation is insecure.

`SECURITY_ERR^c (18)
`NetworkError@err

~network~errorが生じた。 ◎ A network error occurred.

`NETWORK_ERR^c (19)
`AbortError@err

演算は中止された。 ◎ The operation was aborted.

`ABORT_ERR^c (20)
`URLMismatchError@err

所与の URL は他方の URLに合致していない。 ◎ The given URL does not match another URL.

`URL_MISMATCH_ERR^c (21)
`QuotaExceededError@err

quota の上限を超えた。 ◎ The quota has been exceeded.

`QUOTA_EXCEEDED_ERR^c (22)
`TimeoutError@err

演算は時間切れになった。 ◎ The operation timed out.

`TIMEOUT_ERR^c (23)
`InvalidNodeTypeError@err

あてがわれた~nodeは不正か, またはこの演算において不正な先祖を持つ。 ◎ The supplied node is incorrect or has an incorrect ancestor for this operation.

`INVALID_NODE_TYPE_ERR^c (24)
`DataCloneError@err

~objは~cloneできない。 ◎ The object can not be cloned.

`DATA_CLONE_ERR^c (25)
`EncodingError@err

符号化~演算(符号化, 復号の両者を含む)に失敗した。 ◎ The encoding operation (either encoded or decoding) failed.

`NotReadableError@err

I/O 読み取り演算に失敗した。 ◎ The I/O read operation failed.

`UnknownError@err

未知の一時的な事由により,演算に失敗した(例:記憶域を使い切った)。 ◎ The operation failed for an unknown transient reason (e.g. out of memory).

`ConstraintError@err

~transactionにおける変異~演算は、拘束を満たせないため,失敗した。 ◎ A mutation operation in a transaction failed because a constraint was not satisfied.

`DataError@err

提供された~dataは、必要十分でない。 ◎ Provided data is inadequate.

`TransactionInactiveError@err

現在~作動中でない/すでに終わった ~transactionに対し,要請が行われた。 ◎ A request was placed against a transaction which is currently not active, or which is finished.

`ReadOnlyError@err

“読み取り専用” ( `readonly^l ~mode)の~transactionにおいて,変異させようとする演算が試みられた。 ◎ The mutating operation was attempted in a "readonly" transaction.

`VersionError@err

既存の~versionより低い~versionを利用して~databaseを open しようとした。 ◎ An attempt was made to open a database using a lower version than the existing version.

`OperationError@err

演算~特有の事由により,演算に失敗した。 ◎ The operation failed for an operation-specific reason.

`NotAllowedError@err

要請された演算は、現在の文脈においては ~UA/~platform からは — 場合によっては,利用者が否認したことにより — 許容されない。 ◎ The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

3.5. 列挙

`列挙@ は、[ 妥当な値の集合が,定義済みの文字列の集合になる ]ような型を宣言するために利用される,`定義$( `Enum$g に合致)である。 `属性$に代入し得る/`演算$に渡し得る `DOMString$T 値を制約する用途に,列挙を利用できる。 ◎ An enumeration is a definition (matching Enum) used to declare a type whose valid values are a set of predefined strings. Enumerations can be used to restrict the possible DOMString values that can be assigned to an attribute or passed to an operation.

enum `identifier^i { `enumeration-values…^i };

一連の `列挙~値@ は、 `string$g ~literalの~comma区切りの~listとして指定される。 `列挙~値$の~list内に重複があっては~MUST_NOT。 ◎ The enumeration values are specified as a comma-separated list of string literals. The list of enumeration values MUST NOT include duplicates.

別の命名法を利用する理由が特にない限り、列挙~値は,すべて小文字にすることを強く勧める — 複数の単語は,~dashで区切るか全く区切らないことにして。 例えば、~objが作成されるべきであることを指示する列挙~値は, `createobject^l や `create-object^l などと命名できる。 列挙~値の単語を~dashで区切るか区切らないか決めるときは、類似の他の API と一貫するように,関係する列挙~値の利用を考慮に入れること。 ◎ It is strongly suggested that enumeration values be all lowercase, and that multiple words be separated using dashes or not be separated at all, unless there is a specific reason to use another value naming scheme. For example, an enumeration value that indicates an object should be created could be named "createobject" or 'create-object". Consider related uses of enumeration values when deciding whether to dash-separate or not separate enumeration value words so that similar APIs are consistent.

妥当な列挙~値のいずれでもない文字列~値が、列挙~型の`属性$への代入ingや, 列挙~型の`演算$に渡される引数に利用されたときの挙動は、言語束縛~特有になる。 ◎ The behavior when a string value that is not one a valid enumeration value is used when assigning to an attribute, or passed as an operation argument, whose type is the enumeration, is language binding specific.

~JS言語束縛においては、`属性$への妥当でない文字列~値の代入は無視される一方,そのような値を`演算$の引数に渡したときには例外が投出される。 ◎ In the ECMAScript binding, assignment of an invalid string value to an attribute is ignored, while passing such a value as an operation argument results in an exception being thrown.

`列挙$に適用し得る`拡張属性$は、この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to enumerations.

-Enum -EnumValueList -EnumValueListComma -EnumValueListString

次の`~IDL片$は 1個の`属性$と1個の`演算$引数の型として利用される `列挙$を定義する ◎ The following IDL fragment defines an enumeration that is used as the type of an attribute and an operation argument:

enum MealType { "米", "麺", "その他" };

interface Meal {
  attribute MealType type;
  attribute double size;     // グラム~~単位

  void initialize(MealType type, double size);
};

~JS実装は、 type ~propに代入され得る, あるいは `initialize^M 関数に渡され得る文字列を, `列挙$内にて識別されるものに制約することになる。 ◎ An ECMAScript implementation would restrict the strings that can be assigned to the type property or passed to the initializeMeal function to those identified in the enumeration.

var meal = getMeal();            // `Meal^T の~instanceを取得する。

meal.initialize("米", 200);      // 演算は通常通り呼出される。

try {
  meal.initialize("肉", 100);    // `TypeError^t が投出される。
} catch (e) {
}

meal.type = "麺";                // 属性は通常通り代入される。
meal.type = "魚";                // 属性~代入は無視される。
meal.type == "麺";               // `true^v に評価される。

3.6. 呼戻~関数

“Custom DOM Elements” 仕様からは、`呼戻~関数~型$を,~platform~objから提供される関数に利用することが求められている。 “呼戻~関数” を,両方の目的に利用し得ることを明らかにするため、単に “関数” と改称するべきだろうか? ◎ The “Custom DOM Elements” spec wants to use callback function types for platform object provided functions. Should we rename “callback functions” to just “functions” to make it clear that they can be used for both purposes?

`呼戻~関数@ は、関数~型を宣言するときに利用される,`定義$( `callback^sym `CallbackRest$g に合致)である。 ◎ A callback function is a definition (matching "callback" CallbackRest) used to declare a function type.

callback `identifier^i = `return-type^i (`arguments…^i);

似た命名の`呼戻~ifc$も見よ。 ◎ See also the similarly named callback interfaces.

等号の左側の`識別子$が `呼戻~関数$の名前を与える。 等号の右側の[ 返値型( `ReturnType$g に合致) と[ 引数~list( `ArgumentList$g に合致) 【による一連の型】 ]]が,`呼戻~関数~型$の~signatureを与える。 ◎ The identifier on the left of the equals sign gives the name of the callback function and the return type and argument list (matching ReturnType and ArgumentList) on the right side of the equals sign gives the signature of the callback function type.

`呼戻~関数$は `定数$の型に利用されては~MUST_NOT。 ◎ Callback functions MUST NOT be used as the type of a constant.

呼戻~関数には、次の拡張属性を適用し得る: `TreatNonObjectAsNull$x 。 ◎ The following extended attribute is applicable to callback functions: [TreatNonObjectAsNull].

--CallbackOrInterface --CallbackRestOrInterface -CallbackRest

次の`~IDL片$は、演算の完了-時に利用者により定義される関数を呼出す APIのために利用される,`呼戻~関数$を定義する。 ◎ The following IDL fragment defines a callback function used for an API that invokes a user-defined function when an operation is complete.

callback AsyncOperationCallback = void (DOMString status);

interface AsyncOperations {
  void performOperation(AsyncOperationCallback whenFinished);
};

~JS言語束縛においては、 `Function^t ~objは演算~引数として渡される。 ◎ In the ECMAScript language binding, a Function object is passed as the operation argument.

var ops = getAsyncOperations();  // `AsyncOperations^T の~instanceを取得する。

ops.performOperation(function(status) {
  window.alert("Operation finished, status is " + status + ".");
});

3.7. ~typedef

`~typedef@ は、ある型に対し 新たな名前を宣言するために利用される,`定義$( `Typedef$g に合致)である。 この新たな名前は、言語束縛からは公開されない。 これはもっぱら,~IDLにおいて型を参照するための略記法として利用される。 ◎ A typedef is a definition (matching Typedef) used to declare a new name for a type. This new name is not exposed by language bindings; it is purely used as a shorthand for referencing the type in the IDL.

typedef `type^i `identifier^i;

新たな名前が与えられる型( `Type$g に合致)は, `typedef^c ~keywordの後に指定され、型に後続する `identifier$g ~tokが,その新たな名前を与える。 ◎ The type being given a new name is specified after the typedef keyword (matching Type), and the identifier token following the type gives the name.

`Type$g が、同じまたは別の`~typedef$に識別されては~MUST_NOT。 ◎ The Type MUST NOT identify the same or another typedef.

`~typedef$に適用し得る`拡張属性$は、この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to typedefs.

-Typedef

次の`~IDL片$は、`~typedef$を利用して,長い`連列~型$の代わりに短い`識別子$を使えるようしている。 ◎ The following IDL fragment demonstrates the use of typedefs to allow the use of a short identifier instead of a long sequence type.

interface Point {
  attribute double x;
  attribute double y;
};

typedef sequence<Point> Points;

interface Widget {
  boolean pointWithinBounds(Point p);
  boolean allPointsWithinBounds(Points ps);
};

3.8. ~implements文

`~implements文@ は、[[ 文の左側の`識別子$により識別される~ifc %L ]を実装するすべての~objが,[ 文の右側の識別子により識別される追加の~ifc %R ]を, %R が継承する他のすべての~ifcも含めて,実装し~MUST ]ことを宣言するために利用される、`定義$( `ImplementsStatement$g に合致)である。 ◎ An implements statement is a definition (matching ImplementsStatement) used to declare that all objects implementing an interface A (identified by the first identifier) MUST additionally implement interface B (identified by the second identifier), including all other interfaces that B inherits from.

`identifier-L^i implements `identifier-R^i;

%R も,追加の~ifc %R1 を実装するための`~implements文$を伴って宣言されている場合、推移的に, %L を実装するすべての~objは %R1 も追加で実装することになる。 ◎ Transitively, if objects implementing B are declared with an implements statement to additionally implement interface C, then all objects implementing A do additionally implement interface C.

  • %L と %R は異なる~ifcで~MUST。 ◎ The two identifiers MUST identify two different interfaces.
  • %L は %R を`継承-$していては~MUST_NOT。 ◎ The interface identified on the left-hand side of an implements statement MUST NOT inherit from the interface identifier on the right-hand side, and vice versa. Both identified interfaces also MUST NOT be callback interfaces.
  • %R は %L を`継承-$していては~MUST_NOT。 ◎ ↑
  • %L, %R のいずれも,`呼戻~ifc$であっては~MUST_NOT。 ◎ ↑
  • 各`~implements文$を,[ %L を表現する~nodeから %R を表現する~nodeへ向かう,有向~graphの辺 ]と見なすとき、この~graphは循環しては~MUST_NOT。 ◎ If each implements statement is considered to be an edge in a directed graph, from a node representing the interface on the left-hand side of the statement to a node representing the interface on the right-hand side, then this graph MUST NOT have any cycles.

【 記号 %L, %R はここまで。 】

所与の~objが実装する~ifcは、 `追補~ifc@ と見なされるものと, そうでないものに分類される。 ~obj %O の`追補~ifc$は、次のものからなる: ◎ Interfaces that a given object implements are partitioned into those that are considered supplemental interfaces and those that are not. An interface A is considered to be a supplemental interface of an object O if:

  • %O が~ifc %B を実装するならば、 ~IDLにより %B implements %A と言明されている~ifc %A は, %O の追補~ifcである。 ◎ O implements a different interface B, and the IDL states that B implements A; or
  • %O の追補~ifcが`継承-$する~ifcは, %O の追補~ifcである。 ◎ O implements a different supplemental interface C, and C inherits from A.

【 訳では,原文をより構成的な言い回しに変形している — この方が解り易いので。 ~implements文, および継承の定義により, %O はそのすべての追補~ifcを実装することになる。 概念的には, %O が実装するすべての~ifcは[ %O の`主~ifc$, およびその`被継承~ifc$ ]の集合と, %O の追補~ifcの集合に二分されると考えられる。 】

左側の`~ifc$が(ある~objの)`追補~ifc$になるように `~implements文$を記すのは望ましくない。 例えば,仕様~策定者 1 が次を記していたとして: ◎ Specification authors are discouraged from writing implements statements where the interface on the left-hand side is a supplemental interface. For example, if author 1 writes:

interface Window { ... };
interface SomeFunctionality { ... };
Window implements SomeFunctionality;

後に,仕様~策定者 2 が次を記したとする: ◎ and author 2 later writes:

interface Gizmo { ... };
interface MoreFunctionality { ... };
SomeFunctionality implements MoreFunctionality;
Gizmo implements SomeFunctionality;

策定者 2 は、正確にどの~ifcが `implements SomeFunctionality^c 文の左側にすでに利用されたか把握していないこともあり得る。 そのため、予期される以上の~objに対し, `MoreFunctionality^T の実装-が要求され得る。 ◎ then it might be the case that author 2 is unaware of exactly which interfaces already are used on the left-hand side of an implements SomeFunctionality statement, and so has required more objects implement MoreFunctionality than he or she expected.

【 前者の仕様から `SomeFunctionality^T を実装するものと想定されている~obj( `Window^T )が,( `Window^T には~~関係ないかもしれない)後者の仕様により `MoreFunctionality^T も実装しなければならなくなる。 】

このような場合、策定者 2 は次のように記す方が良いであろう: ◎ Better in this case would be for author 2 to write:

interface Gizmo { ... };
interface MoreFunctionality { ... };
Gizmo implements SomeFunctionality;
Gizmo implements MoreFunctionality;

~ifc %A の `帰結~ifc@ は、次のものからなる: ◎ The consequential interfaces of an interface A are:

  • ~IDLにより %A implements %B と言明されている,各~ifc %B, および ◎ each interface B where the IDL states A implements B;
  • %A の帰結~ifcが継承する各~ifc, および ◎ each interface that a consequential interface of A inherits from; and
  • %A の帰結~ifc %C に対し, ~IDLにより %C implements %D と言明されている、各~ifc %D 。 ◎ each interface D where the IDL states that C implements D, where C is a consequential interface of A.

【 概念的には、 %A を実装するにあたって実装-が要求される~ifcすべての集合から, %A 自身および %A の`被継承~ifc$を除いたものと捉えられる。 】

~ifc %B が~ifc %A の `広義~帰結~ifc@ であるとは、 %B は[ %A 自身であるか, または %A の`帰結~ifc$である ]ことを意味する。

【 “広義~帰結~ifc” は、この訳で導入した非公式な用語である — この定義の方が,`帰結~ifc$を~~参照する ほぼすべての記述を簡潔に記せるので。 】

所与の~ifcに対し、その,どの`広義~帰結~ifc$で定義される,どの~mbの識別子も、他の`広義~帰結~ifc$で定義される~mbの識別子と同じになっては~MUST_NOT。 【 同じ~ifc上においては,`多重定義$があり得る。 】 ◎ For a given interface, there MUST NOT be any member defined on any of its consequential interfaces whose identifier is the same as any other member defined on any of those consequential interfaces or on the original interface itself.

例えば、次は許容されない: ◎ For example, that precludes the following:

interface A { attribute long x; };
interface B { attribute long x; };
A implements B;  // `B::x^M と `A::x^M が衝突

interface C { attribute long y; };
interface D { attribute long y; };
interface E : D { };
C implements E;  // `D::y^M と `C::y^M が衝突

interface F { };
interface H { attribute long z; };
interface I { attribute long z; };
F implements H;
F implements I;  // `H::z^M と `I::z^M が `F^T 内に併合される際に衝突

`~implements文$に適用し得る`拡張属性$は、この仕様では定義されない。 ◎ No extended attributes defined in this specification are applicable to implements statements.

-ImplementsStatement

次の`~IDL片$は、2つの`~ifc$を定義する。 一方の~ifcが,他方を実装する~objに常に実装されることを言明する。 ◎ The following IDL fragment defines two interfaces, stating that one interface is always implemented on objects implementing the other.

interface Entry {
  readonly attribute unsigned short entryType;
  // ...
};

interface Observable {
  void addEventListener(DOMString type,
                        EventListener listener,
                        boolean useCapture);
  // ...
};

Entry implements Observable;

~JS実装では、したがって,どの `Entry^T も その原型鎖の中に `addEventListener^l ~propを持つことになる: ◎ An ECMAScript implementation would thus have an “addEventListener” property in the prototype chain of every Entry:

var e = getEntry();         // `Entry^T の~instanceを得る。
typeof e.addEventListener;  // 

すべての `Observable^T ~objが `Entry^T を実装するのではないことに注意。 ◎ Note that it is not the case that all Observable objects implement Entry.

3.9. ~ifcを実装している~obj

`~IDL片$の集合の実装においては、 ~objは `~platform~obj@, `利用者~obj@, またはそのいずれでもないものとして記述され得る。 ~platform~objと見なされる~objは次の2種類に分けられる: ◎ In a given implementation of a set of IDL fragments, an object can be described as being a platform object, a user object, or neither. There are two kinds of object that are considered to be platform objects:

  • `呼戻~ifc$でない`~ifc$を実装する~obj ◎ objects that implement a non-callback interface;
  • ~IDL `DOMException$ を表現する~obj ◎ objects representing IDL DOMExceptions.

~browserにおいては、例えば,[ ~page内で走らせている~JSに対し,~page内容への~accessを提供する ]ために,~browserに実装されている( `Node^T や `Document^T などの~ifcを実装している) DOM ~objが、~platform~objになる。 これらの~objは、 C++ などの言語で実装される~exotic~objになるか, または~native~JS~objになるであろう。 いずれにせよ,所与の~IDL片の集合に対する実装は、[ 実装により作成されたすべての~platform~obj ]を認識できる必要がある。 これは、所与の~objに[ その~objが実装における~platform~objであるかどうかを記録するための,何らかの内的~状態 ]を~~実際に持たせるか、あるいは, おそらく,[ ~objが内部の一定の C++ クラスにより実装されているかどうか ]を見ることにより、実現し得るであろう。 ~platform~objが,正確にどのように実装から認識されるかについては、実装~特有になる。 ◎ In a browser, for example, the browser-implemented DOM objects (implementing interfaces such as Node and Document) that provide access to a web page’s contents to ECMAScript running in the page would be platform objects. These objects might be exotic objects, implemented in a language like C++, or they might be native ECMAScript objects. Regardless, an implementation of a given set of IDL fragments needs to be able to recognize all platform objects that are created by the implementation. This might be done by having some internal state that records whether a given object is indeed a platform object for that implementation, or perhaps by observing that the object is implemented by a given internal C++ class. How exactly platform objects are recognised by a given implementation of a set of IDL fragments is implementation specific.

~system内の他のすべての~objは、~platform~objとしては扱われないことになる。 例えば、~browserが開いた Web ~pageが, DOM Core を実装する~JS~libraryを読込んだとする。 この~libraryは、~browserが提供する実装とは異なる実装として扱われることになる。 ~JS~libraryにより作成された[ `Node^T ~ifcを実装する~obj ]は、~browser実装による[ `Node^T を実装する~platform~obj ]としては扱われないことになる。 ◎ All other objects in the system would not be treated as platform objects. For example, assume that a web page opened in a browser loads an ECMAScript library that implements DOM Core. This library would be considered to be a different implementation from the browser provided implementation. The objects created by the ECMAScript library that implement the Node interface will not be treated as platform objects that implement Node by the browser implementation.

利用者~objとは、[[ 作者により定義される演算を Web API から呼出せるようにする,あるいは Web API からの~objの属性~操作を通して, 作者の~programと値を受け~~渡せるようにする ]ための`呼戻~ifc$ ]を実装するものとして、作者が作成することになる~objである。 Web ~pageにおいては、 DOM Events 実装から呼出される呼戻を登録する際に利用される,[ `EventListener^T ~ifcを実装する~JS~obj ]が、利用者~objと見なされることになる。 ◎ User objects are those that authors would create, implementing callback interfaces that the Web APIs use to be able to invoke author-defined operations or to send and receive values to the author’s program through manipulating the object’s attributes. In a web page, an ECMAScript object that implements the EventListener interface, which is used to register a callback that the DOM Events implementation invokes, would be considered to be a user object.

利用者~objが実装できるのは`呼戻~ifc$のみであり, ~platform~objが実装できるのは非~呼戻~ifcのみであることに注意。 ◎ Note that user objects can only implement callback interfaces and platform objects can only implement non-callback interfaces.

3.10. 型

この節では、 Web IDL で~supportされる型, それぞれの型に対応する値の集合, その型の`定数$がどのように表現されるか, について挙げていく。 ◎ This section lists the types supported by Web IDL, the set of values corresponding to each type, and how constants of that type are represented.

互いに類似する型の集合には、次のような総称が付与されている:

`整数~型@
`byte$T , `octet$T , `short$T , `unsigned short$T , `long$T , `unsigned long$T , `long long$T , `unsigned long long$T ◎ The following types are known as integer types: byte, octet, short, unsigned short, long, unsigned long, long long and unsigned long long.
`実数~型@
すべての`整数~型$ , `float$T , `unrestricted float$T , `double$T , `unrestricted double$T ◎ The following types are known as numeric types: the integer types, float, unresticted float, double and unrestricted double.
`~primitive型@
`boolean$T , すべての`実数~型$ ◎ The primitive types are boolean and the numeric types.
`文字列~型@
`DOMString$T, すべての`列挙~型$ , `ByteString$T, `USVString$T ◎ The string types are DOMString, all enumeration types, ByteString and USVString.
`例外~型@
`Error$T, `DOMException$T ◎ The exception types are Error and DOMException.
`有型~配列~型@
`Int8Array$T, `Int16Array$T, `Int32Array$T, `Uint8Array$T, `Uint16Array$T, `Uint32Array$T, `Uint8ClampedArray$T, `Float32Array$T, `Float64Array$T ◎ The typed array types are Int8Array, Int16Array, Int32Array, Uint8Array, Uint16Array, Uint32Array, Uint8ClampedArray, Float32Array and Float64Array.
`~buffer~source型@
`ArrayBuffer$T, `DataView$T, すべての`有型~配列~型$ ◎ The buffer source types are ArrayBuffer, DataView, and the typed array types.
`~obj~型@
`object$T 型, すべての `~ifc型$, すべての`例外~型$ ◎ The object type, all interface types and the exception types are known as object types.

どの型も,型を識別するための文字列である `型~名@ を持つ — それは一意になるとは限らない。 以下の各~節では、各~型にあてがわれる型~名も定義する。 ◎ Every type has a type name, which is a string, not necessarily unique, that identifies the type. Each sub-section below defines what the type name is for each type.

`演算$の呼出しや`属性$に値を代入する際に必要になる,言語束縛~特有の型から~IDL型への変換はすべて、[ 演算に指定された機能性や 属性~代入 ]が実行に移される前に遂行される。 変換が遂行できない場合、演算は走らされず, 属性は更新されないことになる。 一部の言語束縛では、この型~変換により,例外が投出され得る。 そのような場合、これらの例外は,演算の呼出しや属性への代入-を試みた~codeまで,伝播することになる。 ◎ When conversions are made from language binding specific types to IDL types in order to invoke an operation or assign a value to an attribute, all conversions necessary will be performed before the specified functionality of the operation or attribute assignment is carried out. If the conversion cannot be performed, then the operation will not run or the attribute will not be updated. In some language bindings, type conversions could result in an exception being thrown. In such cases, these exceptions will be propagated to the code that made the attempt to invoke the operation or assign to the attribute.

-Type -SingleType -UnionType -UnionMemberType -UnionMemberTypes -NonAnyType -ConstType -PrimitiveType -UnrestrictedFloatType -FloatType -UnsignedIntegerType -IntegerType -OptionalLong -PromiseType -Null

3.10.1. `any^T

`any$T 型は、 `共用体~型$ 以外のすべての型の和集合である。 その`型~名$は、 `Any^l である。 ◎ The any type is the union of all other possible non-union types. Its type name is “Any”.

`any$T 型は、そのそれぞれの値ごとに固有の非 `any$T 型が結付けられる意味で,~~特別な共用体~型のようなものである。 例えば, `any$T 型のある値は `unsigned long$T 150 をとり得る一方、別の値は `long$T 150 をとり得る。 これらは別々の型の値になる。 ◎ The any type is like a discriminated union type, in that each of its values has a specific non-any type associated with it. For example, one value of the any type is the unsigned long 150, while another is the long 150. These are distinct values.

`any$T 型の個々の値の型は、その `固有型@ と呼ばれる。 ( `共用体~型$の値も`固有型$を持つ。) ◎ The particular type of an any value is known as its specific type. (Values of union types also have specific types.)

【 `any^T 型は, `es-any$sec にも見られるように `null^V 値もとり得るようだが(従って暗黙的な意味で`~nullable$型になると考えられる)、明示的な言及が見当たらない(“すべての型” には~nullable型も含まれる?)。

3.10.2. `boolean^T

`boolean$T 型は2つの値: `true^V と `false^V をとり得る。 ◎ The boolean type has two values: true and false.

~IDLにおいては、 `boolean$T 定数~値は[ `true^c / `false^c ]~tokで表現される。 ◎ boolean constant values in IDL are represented with the true and false tokens.

`boolean$T 型の`型~名$は、 `Boolean^l である。 ◎ The type name of the boolean type is “Boolean”.

3.10.2.3〜10. 整数~型

【 この訳では、原文の 3.2.3 〜 3.2.10 節の内容 — 各種~IDL整数~型の定義を集約して,一括して与える。 】

各種 有符号/無符号 `整数~型$の,とり得る値の範囲, および `型~名$は、次の表で与えられる: ◎ The xxx := (byte|short|long|long long/octet|unsigned short|unsigned long|unsigned long long) type is a (signed/unsigned) integer type that has values in the range ([−P÷2, P÷2 − 1]/[0, P − 1]); P := 2^(8|16|32|64). ◎ xxx constant values in IDL are represented with integer tokens. ◎ The type name of the xxx type is “Xxx”.

~IDL型 最小~値 最大~値 型~名
`byte@T −2`7^sup 2`7^sup − 1 `Byte^l
`octet@T 0 2`8^sup − 1 `Octet^l
`short@T −2`15^sup 2`15^sup − 1 `Short^l
`unsigned short@T 0 2`16^sup − 1 `UnsignedShort^l
`long@T −2`31^sup 2`31^sup − 1 `Long^l
`unsigned long@T 0 2`32^sup − 1 `UnsignedLong^l
`long long@T −2`63^sup 2`63^sup − 1 `LongLong^l
`unsigned long long@T 0 2`64^sup − 1 `UnsignedLongLong^l

~IDLにおいては、どの`整数~型$の定数~値も, `integer$g ~tokで表現される。

3.10.11〜14. 浮動小数点数~型

【 この訳では、原文の 3.10.11 〜 3.10.14 節の内容 — 各種~IDL浮動小数点数~型の定義を集約して,一括して与える。 】

各種 “浮動小数点数 型” — `整数~型$でない`実数~型$ — の,とり得る値の範囲, および `型~名$は、次の表で与えられる:

~IDL型 値の範囲 `IEEE-754$r 型~名
`float@T すべての有限[ 単精度 32 ~bit IEEE 754 浮動小数点数 ]の集合 ◎ The float type is a floating point numeric type that corresponds to the set of finite single-precision 32 bit IEEE 754 floating point numbers. [IEEE-754] `Float^l
`unrestricted float@T すべての有限, 非~有限[ 単精度 32 ~bit IEEE 754 浮動小数点数 ]の集合 ◎ The unrestricted float type is a floating point numeric type that corresponds to the set of all possible single-precision 32 bit IEEE 754 floating point numbers, finite and non-finite. [IEEE-754] `UnrestrictedFloat^l
`double@T すべての有限[ 倍精度 64 ~bit IEEE 754 浮動小数点数 ]の集合 ◎ The double type is a floating point numeric type that corresponds to the set of finite double-precision 64 bit IEEE 754 floating point numbers. [IEEE-754] `Double^l
`unrestricted double@T すべての有限, 非~有限[ 倍精度 64 ~bit IEEE 754 浮動小数点数 ]の集合 ◎ The unrestricted double type is a floating point numeric type that corresponds to the set of all possible double-precision 64 bit IEEE 754 floating point numbers, finite and non-finite. [IEEE-754] `UnrestrictedDouble^l

~IDLにおいては、どの浮動小数点数 型の定数~値も, `float$g ~tokで表現される。 ◎ The type name of the( xxx)? yyy type is “(Xxx)Yyy”.

特に 32 ~bit浮動小数点~型を利用する理由が無い限り,仕様は `float$T でなく,`double$T を利用する~SHOULD。 `double$T が表現し得る値~集合は,より近く~JS `Number^t に合致するので。 ◎ Unless there are specific reasons to use a 32 bit floating point type, specifications SHOULD use double rather than float, since the set of values that a double can represent more closely matches an ECMAScript Number.

3.10.15. `DOMString^T

`DOMString$T 型は、可能なすべての[ `符号単位$の並び ]の集合に対応する。 そのような並びは、共通的に, UTF-16 符号化~文字列 `RFC2781$r として解釈されるが、要求されてはいない。 `DOMString$T は DOM Level 3 Core ( `DOM3CORE$r, 1.2.1 節) において[ OMG IDL boxed sequence<unsigned short> valuetype ]として定義されているが、この文書は,文字列が要求される様々な状況における,その連列~型に対する特別な場合分けを避けるため、 `DOMString$T を内在的な型として定義する。 ◎ The DOMString type corresponds to the set of all possible sequences of code units. Such sequences are commonly interpreted as UTF-16 encoded strings [RFC2781] although this is not required. While DOMString is defined to be an OMG IDL boxed sequence<unsigned short> valuetype in DOM Level 3 Core ([DOM3CORE], section 1.2.1), this document defines DOMString to be an intrinsic type so as to avoid special casing that sequence type in various situations where a string is required.

`null^V は `DOMString$T の値ではないことにも注意。 ~IDLにおいて `null^V を許容するためには, DOMString? と記される ~nullable `DOMString$T を利用する必要がある。 ◎ Note also that null is not a value of type DOMString. To allow null, a nullable DOMString, written as DOMString? in IDL, needs to be used.

この仕様においては、 `DOMString$T 値が妥当な UTF-16 文字列であることは要求されない。 例えば, `DOMString$T 値は、対になっていない代用対( surrogate pair )文字も含み得る。 しかしながら, Web IDL を利用する仕様の策定者は、所与の個々の[ `符号単位$の並び ]から Unicode ~scalar値~列を得たいと求めることもあろう。 次の~algoは、 `DOMString$T 値 %S を `Unicode ~scalar値~列に変換-@ する仕方を定義する: ◎ Nothing in this specification requires a DOMString value to be a valid UTF-16 string. For example, a DOMString value might include unmatched surrogate pair characters. However, authors of specifications using Web IDL might want to obtain a sequence of Unicode scalar values given a particular sequence of code units. The following algorithm defines a way to convert a DOMString to a sequence of Unicode scalar values:

  1. %n := %S の長さ ◎ Let S be the DOMString value. ◎ Let n be the length of S.
  2. %i :← 0 ◎ Initialize i to 0.
  3. %U :← Unicode 文字の空~連列 ◎ Initialize U to be an empty sequence of Unicode characters.
  4. ~WHILE %i < %n : ◎ While i < n:

    1. %c := %S 内で~index %i に位置する`符号単位$ ◎ Let c be the code unit in S at index i.
    2. %c の値に応じて: ◎ Depending on the value of c:

      %c < 0xD800
      %c > 0xDFFF

      符号位置 %c の Unicode 文字を %U に付加する ◎ Append to U the Unicode character with code point c.

      0xDC00 ≤ %c ≤ 0xDFFF

      ~REPLACEMENT を %U に付加する ◎ Append to U a U+FFFD REPLACEMENT CHARACTER.

      0xD800 ≤ %c ≤ 0xDBFF
      1. ~IF %i + 1 ≥ %n ~THEN ~REPLACEMENT を %U に付加する ◎ If i = n−1, then append to U a U+FFFD REPLACEMENT CHARACTER.
      2. ~ELSE ⇒ ◎ Otherwise, i < n−1:

        1. %d := %S 内の~index %i + 1 に位置する`符号単位$ ◎ Let d be the code unit in S at index i+1.
        2. ~IF 0xDC00 ≤ %d ≤ 0xDFFF ⇒ ◎ If 0xDC00 ≤ d ≤ 0xDFFF, then:

          1. 符号位置 [ 2`16^sup + 2`10^sup × ( %c & 0x3FF ) + ( %d & 0x3FF ) ]の Unicode 文字を %U に付加する ◎ Let a be c & 0x3FF. ◎ Let b be d & 0x3FF. ◎ Append to U the Unicode character with code point 2^16 + 2^10 a+b.
          2. %i ← %i + 1 ◎ Set i to i+1.
        3. ~ELSE ~THEN ~REPLACEMENT を %U に付加する ◎ Otherwise, d < 0xDC00 or d > 0xDFFF. Append to U a U+FFFD REPLACEMENT CHARACTER.
    3. %i ← %i + 1 ◎ Set i to i+1.
  5. ~RET %U ◎ Return U.

~IDLにおいて,定数 `DOMString$T 値を表現する仕方は、ない。 `string$g ~literalを利用して, `DOMString$T 型の[ `辞書~mb$ / 演算の`随意~引数$ ]に既定~値を指定することはできる。 ◎ There is no way to represent a constant DOMString value in IDL, although DOMString dictionary member and operation optional argument default values can be specified using a string literal.

`DOMString$T 型の`型~名$は、 `String^l である。 ◎ The type name of the DOMString type is “String”.

3.10.16. `ByteString^T

`ByteString$T 型は、可能なすべての[ byte の並び ]の集合に対応する。 その種の並びは、要求されてはいないが,[ UTF-8 に符号化された文字列 `RFC3629$r, あるいは[ 他の何らかの[ 1 符号単位あたり 8 ~bit ]になる符号化方式 ]により符号化された文字列 ]に解釈し得る。 ◎ The ByteString type corresponds to the set of all possible sequences of bytes. Such sequences might be interpreted as UTF-8 encoded strings [RFC3629] or strings in some other 8-bit-per-code-unit encoding, although this is not required.

~IDLにおいて,定数 `ByteString$T 値を表現する仕方は、ない。 ◎ There is no way to represent a constant ByteString value in IDL.

`ByteString$T 型の`型~名$は、 `ByteString^l である。 ◎ The type name of the ByteString type is “ByteString”.

仕様は、[ HTTP などの, byte や文字列を交換可能な~~形で利用する~protocol ]とのやりとりのみに, `ByteString$T を利用する~SHOULD。 一般に、文字列は,その値が[ 常に ASCII または 何らかの 8 ~bit文字~符号化方式 ]になることが期待されているとしても, `DOMString$T 値により表現される~SHOULD。 8 ~bit~dataを保持するためには、`ByteString$T ではなく,[ `octet$T または `byte$T ]を要素とする[ `連列~型$ / `凍結~配列~型$ / Typed Arrays `TYPEDARRAYS$r ]が利用される~SHOULD。 【 Typed Arrays は~buffer~source型( `idl-buffer-source-types$sec )に置き換わっている — 更新漏れ? 】 ◎ Specifications SHOULD only use ByteString for interfacing with protocols that use bytes and strings interchangably, such as HTTP. In general, strings SHOULD be represented with DOMString values, even if it is expected that values of the string will always be in ASCII or some 8 bit character encoding. Sequences, frozen arrays or Typed Arrays with octet or byte elements SHOULD be used for holding 8 bit data rather than ByteString. [TYPEDARRAYS]

3.10.17. `USVString^T

`USVString$T 型は、可能なすべての[[ `Unicode ~scalar値$ — ~surrogate符号位置でない Unicode 符号位置 ]の並び ]の集合に対応する。 ◎ The USVString type corresponds to the set of all possible sequences of Unicode scalar values, which are all of the Unicode code points apart from the surrogate code points.

~IDLにおいて,定数 `USVString$T 値を表現する仕方は、ない。 `string$g ~literalを利用して, `USVString$T 型の[ `辞書~mb$ / 演算の`随意~引数$ ]に既定~値を指定することはできる。 ◎ There is no way to represent a constant USVString value in IDL, although USVString dictionary member and operation optional argument default values can be specified using a string literal.

`USVString$T 型の`型~名$は、 `USVString^l である。 ◎ The type name of the USVString type is “USVString”.

仕様は、[ ~text処理を遂行する際に Unicode ~scalar値による文字列~演算が必要になる ]ときにのみ, API に `USVString$T を利用する~SHOULD。 文字列を利用する ほとんどの API は、文字列~内の`符号単位$に いかなる解釈も行わない `DOMString$T を利用するべきである。 疑わしい場合は `DOMString$T を利用すること。 ◎ Specifications SHOULD only use USVString for APIs that perform text processing and need a string of Unicode scalar values to operate on. Most APIs that use strings should instead be using DOMString, which does not make any interpretations of the code units in the string. When in doubt, use DOMString.

3.10.18. `object^T

`object$T 型は、可能なすべての[ 非 `null^V ~obj参照 ]の集合に対応する。 ◎ The object type corresponds to the set of all possible non-null object references.

~IDLにおいて,定数 `object$T 値を表現する仕方は、ない。 ◎ There is no way to represent a constant object value in IDL.

可能なすべての~obj参照に加えて, `null^V 値も内包する型を表すためには、 `~nullable型$ `object?^T を利用する。 ◎ To denote a type that includes all possible object references plus the null value, use the nullable type object?.

`object$T 型の`型~名$は、 `Object^l である。 ◎ The type name of the object type is “Object”.

3.10.19. ~ifc型

`~ifc$を識別する`識別子$は、その~ifcを実装する,可能なすべての[ 非 `null^V ~obj参照の集合 ]に対応する型を指すために利用される。 ◎ An identifier that identifies an interface is used to refer to a type that corresponds to the set of all possible non-null references to objects that implement that interface.

非~呼戻~ifcに対する~ifc型の~IDL値は,単に~obj参照により表現される。 `呼戻~ifc$ に対しては、~ifc型の~IDL値は[ ~obj参照, `呼戻~文脈$ ]の組により表現される。 `呼戻~文脈@ とは、言語束縛~特有の値であり、[ 言語束縛~特有の~obj参照が~IDL値に変換される時点における,実行~文脈についての情報 ]を格納するために利用されるものである。 ◎ For non-callback interfaces, an IDL value of the interface type is represented just by an object reference. For callback interfaces, an IDL value of the interface type is represented by a tuple of an object reference and a callback context. The callback context is a language binding specific value, and is used to store information about the execution context at the time the language binding specific object reference is converted to an IDL value.

~JS~objに対しては、`呼戻~文脈$は, `Object^t 値が~IDL呼戻~ifc型の値に変換される時点の `~incumbent設定群~obj$ `HTML$r への参照を保持するために利用される。 `es-interface$sec を見よ。 ◎ For ECMAScript objects, the callback context is used to hold a reference to the incumbent settings object [HTML] at the time the Object value is converted to an IDL callback interface type value. See section 4.2.20 below.

~IDLにおいて,個々の~ifc型の定数~obj参照~値を表現する仕方は、ない。 ◎ There is no way to represent a constant object reference value for a particular interface type in IDL.

所与の~ifcを実装する,可能なすべての~obj参照に加えて、 `null^V 値も内包する型を表すためには,`~nullable型$を利用する。 ◎ To denote a type that includes all possible references to objects implementing the given interface plus the null value, use a nullable type.

~ifc型の`型~名$は、その~ifcの`識別子$である。 ◎ The type name of an interface type is the identifier of the interface.

3.10.20. 辞書~型

`辞書$を識別する`識別子$は、[ 辞書~定義に~~寄与する,すべての辞書の集合 ]に対応する型を指すために利用される。 ◎ An identifier that identifies a dictionary is used to refer to a type that corresponds to the set of all dictionaries that adhere to the dictionary definition.

~IDLにおいて,定数~辞書~値を表現する仕方は、ない。 ◎ There is no way to represent a constant dictionary value in IDL.

辞書~型の`型~名$は、その辞書の`識別子$である。 ◎ The type name of a dictionary type is the identifier of the dictionary.

3.10.21. 列挙~型

`列挙$を識別する`識別子$は、[ その`列挙~値$に属する文字列( `DOMString$T と同様の,`符号単位$の並び)の集合 ]を値にとる型を指すために利用される。 ◎ An identifier that identifies an enumeration is used to refer to a type whose values are the set of strings (sequences of code units, as with DOMString) that are the enumeration’s values.

`DOMString$T と同様に、 ~IDLにおいて,定数`列挙$値を表現する仕方は、ない。 `string$g ~literalを利用して、列挙~型にされた`辞書~mb$に `辞書既定値^を指定することはできる。 ◎ Like DOMString, there is no way to represent a constant enumeration value in IDL, although enumeration-typed dictionary member default values can be specified using a string literal.

列挙~型の`型~名$は、その列挙の`識別子$である。 ◎ The type name of an enumeration type is the identifier of the enumeration.

3.10.22. 呼戻~関数~型

`呼戻~関数$を識別する`識別子$は、[ 所与の~signatureを伴う関数~objへの参照 ]を値にとる型を指すために利用される。 ◎ An identifier that identifies a callback function is used to refer to a type whose values are references to objects that are functions with the given signature.

呼戻~関数~型の~IDL値は,[ ~obj参照, `呼戻~文脈$ ]の組により表現される。 ◎ An IDL value of the callback function type is represented by a tuple of an object reference and a callback context.

`~ifc型$と同様に、`呼戻~文脈$は, ~JS `Object^t 値が~IDL呼戻~ifc型の値に変換される時点の `~incumbent設定群~obj$ `HTML$r への参照を保持するために利用される。 `es-callback-function$sec を見よ。 ◎ As with callback interface types, the callback context is used to hold a reference to the incumbent settings object [HTML] at the time an ECMAScript Object value is converted to an IDL callback function type value. See section 4.2.23 below.

~IDLにおいて,定数 `呼戻~関数$値を表現する仕方は、ない。 ◎ There is no way to represent a constant callback function value in IDL.

呼戻~関数~型の`型~名$は、その呼戻~関数の`識別子$である。 ◎ The type name of a callback function type is the identifier of the callback function.

3.10.23. ~nullable型 — `~varT?^T

`~nullable型@ は、(その `内縁~型@ と呼ばれる)既存の型から構築される~IDL型であり、とり得る値の集合は,内縁~型がとり得る値に値 `null^V のみを~~追加したものになる。 ~IDLにおいては、`~nullable型$は,既存の型の後に 文字 `U+003F QUESTION MARK ("?")^char を置いて表現される。 `内縁~型$は次のいずれであっても~MUST_NOT:

  • `any$T 型
  • 別の~nullable型
  • `共用体~型$であって[ それ自身が`~nullable型を内包する$, または その`平坦化~mb型$に辞書~型が含まれている ]もの。
◎ A nullable type is an IDL type constructed from an existing type (called the inner type), which just allows the additional value null to be a member of its set of values. Nullable types are represented in IDL by placing a U+003F QUESTION MARK ("?") character after an existing type. The inner type MUST NOT be any, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types.

辞書~型は,一般には~nullableになれるが、その場合,演算~引数や辞書~mbの型には利用できない。 ◎ Although dictionary types can in general be nullable, they cannot when used as the type of an operation argument or a dictionary member.

~IDLにおいては、~nullable型の定数~値は,その`内縁~型$の定数~値と同じ仕方で表現されるか, または `null^c ~tokで表現される。 ◎ Nullable type constant values in IDL are represented in the same way that constant values of their inner type would be represented, or with the null token.

~nullable型の`型~名$は、[ その内縁~型 %T の型~名, 文字列 `OrNull^l ]の連結である。 ◎ The type name of a nullable type is the concatenation of the type name of the inner type T and the string “OrNull”.

例えば、値 `true^V, `false^V, `null^V をとり得る型は, `boolean?^T と記される: ◎ For example, a type that allows the values true, false and null is written as boolean?:

interface MyConstants {
  const boolean? ARE_WE_THERE_YET = false;
};

次の`~ifc$は2個の`属性$を持つ。 一方は `DOMString$T または `null^V 値を値にとり得る。 他方は `Node^T ~objへの参照または `null^V 値を値にとり得る: ◎ The following interface has two attributes: one whose value can be a DOMString or the null value, and another whose value can be a reference to a Node object or the null value:

interface Node {
  readonly attribute DOMString? namespaceURI;
  readonly attribute Node? parentNode;
  // ...
};

3.10.24. 連列~型 — `sequence<~varT>^T

`sequence_T^ 型は、[[ 型 %T の値 ]の連列(長さゼロも許容される) ]を値にとり得るような,~parameter化された型である。 ◎ The sequence<T> type is a parameterized type whose values are (possibly zero-length) sequences of values of type T.

連列は常に値渡しである。 連列が何らかの種類の~objで表現される言語束縛においても、`~platform~obj$に連列が渡された際に,その連列への参照が~objに保有されることはない。 同様に,~platform~objから返されるどの連列も複製であり、それに対する改変は~platform~objからは見えないことになる。 ◎ Sequences are always passed by value. In language bindings where a sequence is represented by an object of some kind, passing a sequence to a platform object will not result in a reference to the sequence being kept by that object. Similarly, any sequence returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

~IDLにおいて,定数~連列~値を表現する仕方は、ない。 ◎ There is no way to represent a constant sequence value in IDL.

連列は[ `属性$/`定数$ ]の型に利用されては~MUST_NOT。 ◎ Sequences MUST NOT be used as the type of an attribute or constant.

この制約は、[ `連列~型$は、その参照が渡し回されるものではなく,複製されるものである ]ことを,仕様~策定者や利用者から見て明らかにするためにある。 連列~型の~writableな`属性$には、代わりに,連列を取得-/設定する`演算$~pairの利用を勧める。 ◎ This restriction exists so that it is clear to specification writers and API users that sequences are copied rather than having references to them passed around. Instead of a writable attribute of a sequence type, it is suggested that a pair of operations to get and set the sequence is used.

連列~型の`型~名$は、[ %T の型~名, 文字列 `Sequence^l ]の連結である。 ◎ The type name of a sequence type is the concatenation of the type name for T and the string “Sequence”.

3.10.25. ~promise型 — `Promise<~varT>^T

`~promise~型@ は、[[ “[[ 非同期 演算において,延期され得る(非同期にもなり得る)計算 ]の最終的な結果† ]への~place-holder” `ECMA-262$r ]として利用される~obj ]への参照を値にとるような,~parameter化された型である。 ~promise~objの意味論についての詳細は~JS仕様 25.4 節 に。 ◎ A promise type is a parameterized type whose values are references to objects that “is used as a place holder for the eventual results of a deferred (and possibly asynchronous) computation result of an asynchronous operation” [ECMA-262]. See section 25.4 of the ECMAScript specification for details on the semantics of promise objects.

【† %T が,結果の値の型を与える。 】

~IDLにおいて,~promise値を表現する仕方は、ない。 ◎ There is no way to represent a promise value in IDL.

~promise型の`型~名$は、[ %T の型~名, 文字列 `Promise^l ]の連結である。 ◎ The type name of a promise type is the concatenation of the type name for T and the string “Promise”.

3.10.26. 共用体~型

`~共用体~型@ は、とり得る値の集合が 複数の型の値の和集合であるような,型である。 共用体~型( `UnionType$g に合致)は、 `or^c ~keywordで区切られた型の並びを左右~丸括弧で括って記される。 共用体~型を構成する型は、共用体の `~mb型@ と呼ばれる。 ◎ A union type is a type whose set of values is the union of those in two or more other types. Union types (matching UnionType) are written as a series of types separated by the or keyword with a set of surrounding parentheses. The types which comprise the union type are known as the union’s member types.

例えば, `(Node or DOMString)^c や `(double or sequence<double>)^c などのように記す。 `共用体~型$に全体として `?^c 接尾辞を適用するときは, `(Node or DOMString)?^c のように,右~丸括弧の後に置く。 ◎ For example, you might write (Node or DOMString) or (double or sequence<double>). When applying a ? suffix to a union type as a whole, it is placed after the closing parenthesis, as in (Node or DOMString)?.

共用体~型の`~mb型$は、入子にされた共用体~型にまでは掘り下げられないことに注意。 したがって, `(double or (sequence<long> or Event) or (Node or DOMString)?)^c に対する~mb型は `double^T , `(sequence<long> or Event)^T , `(Node or DOMString)?^T になる。 ◎ Note that the member types of a union type do not descend into nested union types. So for (double or (sequence<long> or Event) or (Node or DOMString)?) the member types are double, (sequence<long> or Event) and (Node or DOMString)?.

`any$T 型と同様、共用体~型の値は,その値に合致するいずれか一つの`~mb型$を`固有型$として持つ。 ◎ Like the any type, values of union types have a specific type, which is the particular member type that matches the value.

`共用体~型$ %T の `平坦化~mb型@ とは、次の手続きで決定される型の集合である: ◎ The flattened member types of a union type is a set of types determined as follows:

  1. %S :← ∅ ◎ Let T be the union type. ◎ Initialize S to ∅.
  2. ~FOR %T 内の~EACH ( `~mb型$ %U ) に対し: ◎ For each member type U of T:

    1. ~IF %U は `~nullable型$である ~THEN %U ← %U の`内縁~型$ ◎ If U is a nullable type, then set U to be the inner type of U.
    2. ~IF %U は `共用体~型$である ~THEN %U の`平坦化~mb型$に属するすべての型を %S に追加する ◎ If U is a union type, then add to S the flattened member types of U.
    3. ~ELSE ~THEN %U を %S に追加する ◎ Otherwise, U is not a union type. Add U to S.
  3. ~RET %S ◎ Return S.

例えば,`共用体~型$ `(Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>)^c の`平坦化~mb型$は、6つの型[ `Node^T , `sequence<long>^T , `Event^T , `XMLHttpRequest^T , `DOMString^T , `sequence<(sequence<double> or NodeList)>^T ]からなる。 ◎ For example, the flattened member types of the union type (Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>) are the six types Node, sequence<long>, Event, XMLHttpRequest, DOMString and sequence<(sequence<double> or NodeList)>.

`共用体~型$ %T の `~nullable~mb型の個数@ とは、次の手続きで決定される整数である: ◎ The number of nullable member types of a union type is an integer determined as follows:

  1. %n :← 0 ◎ Let T be the union type. ◎ Initialize n to 0.
    1. ~IF %U は `~nullable型$である ⇒ ◎ If U is a nullable type, then:

      1. %n ← %n + 1 ◎ Set n to n + 1.
      2. %U ← %U の`内縁~型$ ◎ Set U to be the inner type of U.
    2. ~IF %U は `共用体~型$である ⇒ ◎ If U is a union type, then:

      1. %m := %U の`~nullable~mb型の個数$ ◎ Let m be the number of nullable member types of U.
      2. %n ← %n + %m ◎ Set n to n + m.
  2. ~RET %n ◎ Return n.

`~mb型$に `any$T 型が利用されては~MUST_NOT。 ◎ The any type MUST NOT be used as a union member type.

`共用体~型$の `~nullable~mb型の個数$ は 0 か 1 で~MUST。 1 の場合、その共用体~型は`平坦化~mb型$に辞書~型を持っては~MUST_NOT。 ◎ The number of nullable member types of a union type MUST be 0 or 1, and if it is 1 then the union type MUST also not have a dictionary type in its flattened member types.

次を満たす型は `~nullable型を内包する@ とされる。 ◎ A type includes a nullable type if:

  • `~nullable型$である, または ◎ the type is a nullable type, or
  • `共用体~型$であり, かつ その `~nullable~mb型の個数$が 0 でない( 1 である)。 ◎ the type is a union type and its number of nullable member types is 1.

【 概念的には, `null^V を値にとり得る型と考えられる。 ただし、この定義では `any$T 型は含まれないことになる。 】

`共用体~型$の`平坦化~mb型$に属する どの2つの型も`判別可能$で~MUST。 ◎ Each pair of flattened member types in a union type, T and U, MUST be distinguishable.

~IDLにおいては、`共用体~型$の定数~値は,それらの`~mb型$の定数~値と同じ仕方で表現される。 ◎ Union type constant values in IDL are represented in the same way that constant values of their member types would be represented.

共用体~型の`型~名$は、その各~mb型の型~名を順に,文字列 `Or^l で連結したものである。 ◎ The type name of a union type is formed by taking the type names of each member type, in order, and joining them with the string “Or”.

--UnionType --UnionMemberType --UnionMemberTypes --NonAnyType

3.10.27. `RegExp^T

`RegExp$T 型は、[ 正規表現を表現する~obj ]への参照を値にとる型である。 特定0の正規表現~言語や,それが~supportする特色機能は、言語束縛~特有になる。 ◎ The RegExp type is a type whose values are references to objects that represent regular expressions. The particular regular expression language and the features it supports is language binding specific.

~IDLにおいて,定数 `RegExp$T 値を表現する仕方は、ない。 ◎ There is no way to represent a constant RegExp value in IDL.

`RegExp$T の`型~名$は、 `RegExp^l である。 ◎ The type name of the RegExp type is “RegExp”.

3.10.28. `Error^T

`Error$T 型は、[ `単純例外$, `DOMException$ ]を含む,可能なすべての[ 非 null 例外~objへの参照 ]の集合に対応する。 ◎ The Error type corresponds to the set of all possible non-null references to exception objects, including simple exceptions and DOMExceptions.

~IDLにおいて,定数 `Error$T 値を表現する仕方は、ない。 ◎ There is no way to represent a constant Error value in IDL.

`Error$T の`型~名$は、 `Error^l である。 ◎ The type name of the Error type is “Error”.

3.10.29. `DOMException^T

`DOMException$T 型は、可能なすべての[ 非 `null^V `DOMException$ を表現する~obj参照 ]の集合に対応する。 ◎ The DOMException type corresponds to the set of all possible non-null references to objects representing DOMExceptions.

~IDLにおいて,定数 `DOMException$T 値を表現する仕方は、ない。 ◎ There is no way to represent a constant DOMException value in IDL.

`DOMException$T の`型~名$は、 `DOMException^l である。 ◎ The type name of the DOMException type is “DOMException”.

3.10.30. ~buffer~source型

可能なすべての[[[ ~dataの~buffer, または[ ~dataの~buffer上の~view ]]を表現する~obj ]への 非 `null^V 参照 ]の集合に対応する,いくつかの型がある。 下の一覧に、それらの型, および それらが表現する[ ~bufferまたは その~view ]の種類を挙げる。 ◎ There are a number of types that correspond to sets of all possible non-null references to objects that represent a buffer of data or a view on to a buffer of data. The table below lists these types and the kind of buffer or view they represent.

型◎Type ~bufferの種類◎Kind of buffer
`ArrayBuffer@T 固定的な個数の~byteからなる~bufferへの~pointer( `null^V もとり得る)を保持する~obj。 ◎ An object that holds a pointer (which may be null) to a buffer of a fixed number of bytes
`DataView@T `ArrayBuffer$T への~viewであって、~bufferの中の,任意の~offsetに格納されている 整数/浮動小数点 値への~accessを可能にするもの。 ◎ A view on to an ArrayBuffer that allows typed access to integers and floating point values stored at arbitrary offsets into the buffer
`Int8Array@T,
`Int16Array@T,
`Int32Array@T
`ArrayBuffer$T への~viewであって、[ 所与の~bit~sizeの 2の補数による有符号~整数からなる配列 ]を公開するもの。 ◎ A view on to an ArrayBuffer that exposes it as an array of two’s complement signed integers of the given size in bits
`Uint8Array@T,
`Uint16Array@T,
`Uint32Array@T
`ArrayBuffer$T への~viewであって、[ 所与の~bit~sizeの 無符号~整数からなる配列 ]を公開するもの。 ◎ A view on to an ArrayBuffer that exposes it as an array of unsigned integers of the given size in bits
`Uint8ClampedArray@T `ArrayBuffer$T への~viewであって、値を切詰める変換も伴われるような,[ 8~bit無符号~整数からなる配列 ]を公開するもの。 ◎ A view on to an ArrayBuffer that exposes it as an array of unsigned 8 bit integers with clamped conversions
`Float32Array@T,
`Float64Array@T
`ArrayBuffer$T への~viewであって、[ 所与の~bit~sizeの IEEE 754 浮動小数点数 ]からなる配列を公開するもの。 ◎ A view on to an ArrayBuffer that exposes it as an array of IEEE 754 floating point numbers of the given size in bits

これらの型はすべて、~JSにて定義される~classに対応する。 ◎ These types all correspond to classes defined in ECMAScript.

`ArrayBuffer$T ~objを `切離す@ とは、その~bufferへの~pointerを `null^v に設定することである。 ◎ To detach an ArrayBuffer is to set its buffer pointer to null.

これらのどの型についても、 ~IDLにおいて,その型の定数~値を表現する仕方は、ない。 ◎ There is no way to represent a constant value of any of these types in IDL.

これらのどの型についても,その`型~名$は、その型~自身の名前である。 ◎ The type name of all of these types is the name of the type itself.

仕様の中の注釈文~levelにおいては、~IDL`~buffer~source型$は,単純に~objへの参照である。 仕様の注釈文にて,~buffer内の~byte列を 検分したり操作するときは、最初に,~buffer~sourceに保持されている~byte列の `参照/複製を取得-@ する手続きを介さ~MUST。 仕様の注釈文では、その結果の~byte列への参照/複製を利用して,個々の~byte値を取得したり設定できる。 ◎ At the specification prose level, IDL buffer source types are simply references to objects. To inspect or manipulate the bytes inside the buffer, specification prose MUST first either get a reference to the bytes held by the buffer source or get a copy of the bytes held by the buffer source. With a reference to the buffer source’s bytes, specification prose can get or set individual byte values using that reference.

仕様において、[ ~buffer~sourceに保持されている~byteへの参照を取得する ]ような ~textを書くときには、細心の注意を払う必要がある — 下層の~dataは、予測し得ない時に作者や他の API により,容易に変更され得るので。 改変されないような ~binary~dataの~chunkを得るために,演算~引数として~buffer~source型を利用する場合は、その演算を定義する注釈文の始めの方で,~buffer~sourceの~byte列の複製を取得することが、強く推奨される。 ◎ Extreme care must be taken when writing specification text that gets a reference to the bytes held by a buffer source, as the underyling data can easily be changed by the script author or other APIs at unpredictable times. If you are using a buffer source type as an operation argument to obtain a chunk of binary data that will not be modified, it is strongly recommended to get a copy of the buffer source’s bytes at the beginning of the prose defining the operation.

~byte列の 参照/複製 を取得する明示的な注釈文を要することの意図は、仕様の査読者が,これらの~buffer~source型の利用に孕まれる問題を見つけ易くするためである。 ◎ Requiring prose to explicitly get a reference to or copy of the bytes is intended to help specification reviewers look for problematic uses of these buffer source types.

~bufferを~~入力にとる API を設計するときは、 `ArrayBuffer$T や他の~view~型よりも `BufferSource^T ~typedefの利用が推奨される。 ◎ When designing APIs that take a buffer, it is recommended to use the BufferSource typedef rather than ArrayBuffer or any of the view types.

~bufferを作成したり返す API を設計するときは、 `Uint8Array$T よりも `ArrayBuffer$T 型の利用が推奨される。 ◎ When designing APIs that create and return a buffer, it is recommended to use the ArrayBuffer type rather than Uint8Array.

`切離された$ `ArrayBuffer$T ~objに対し,~buffer~sourceに保持されている~byte列の`参照/複製を取得-$しようと試みたときは、言語束縛~特有の方式で失敗することになる。 ◎ Attempting to get a reference to or get a copy of the bytes held by a buffer source when the ArrayBuffer has been detached will fail in a language binding-specific manner.

~JS言語束縛において ~buffer~source型とのやりとりがどのように働くかについては、`es-buffer-source-types$secに。 ◎ See section 4.2.31 below for how interacting with buffer source types works in the ECMAScript language binding.

これらの型や用語を利用する仕様~textの例を含ませる必要がある。 ◎ We should include an example of specification text that uses these types and terms.

3.10.31. 凍結~配列~型 — `FrozenArray<~varT>^T

`~凍結~配列~型@ は、[[[ 一連の[ 改変できない,型 ~varT の値 ]からなる,固定長の配列 ]を保持する~obj ]への参照 ]を値にとり得るような,~parameter化された型である。 ◎ A frozen array type is a parameterized type whose values are references to objects that hold a fixed length array of unmodifiable values. The values in the array are of type T.

`FrozenArray_T^ 値は参照である — 値の~listであり,値渡しである`連列~型$と違って。 ◎ Since FrozenArray<T> values are references, they are unlike sequence types, which are lists of values that are passed by value.

~IDLにおいて,定数~凍結~配列~値を表現する仕方は、ない。 ◎ There is no way to represent a constant frozen array value in IDL.

凍結~配列~型の`型~名$は、[ %T の型~名, 文字列 `Array^l ]の連結である。 ◎ The type name of a frozen array type is the concatenation of the type name for T and the string “Array”.

3.11. 拡張属性

`拡張属性@ は、[ `定義$ / `~ifc~mb$ / `辞書~mb$ / `演算$引数 ]上に現れ得る 注釈 ( annotation )であり,[ 言語束縛がこれらの構成子をどう取扱うことになるか ]を制御するために利用される。 拡張属性は `ExtendedAttributeList$g により指定される。 それは、全体が角括弧で括られた,いくつかの `ExtendedAttribute$g からなる~comma区切りの~listである。 ◎ An extended attribute is an annotation that can appear on definitions, interface members, dictionary members, and operation arguments, and is used to control how language bindings will handle those constructs. Extended attributes are specified with an ExtendedAttributeList, which is a square bracket enclosed, comma separated list of ExtendedAttributes.

文法~記号 `ExtendedAttribute$g は,ほぼ任意の~tok並びに合致するが、この文書で定義される`拡張属性$は,より制約された構文のみを受容する。 `~IDL片$に~~現れるどの拡張属性も、次の表に示す文法~記号のいずれかへの合致により、それが属する(1つ以上の)形が決定される: ◎ The ExtendedAttribute grammar symbol matches nearly any sequence of tokens, however the extended attributes defined in this document only accept a more restricted syntax. Any extended attribute encountered in an IDL fragment is matched against the following six grammar symbols to determine which form (or forms) it is in:

文法~記号◎Grammar symbol 形◎Form 例◎Example
`ExtendedAttributeNoArgs$g `引数をとらない@ `[Replaceable]^c
`ExtendedAttributeArgList$g `引数~listを引数にとる@ `[Constructor(double x, double y)]^c
`ExtendedAttributeNamedArgList$g `有名~引数~listを引数にとる@ `[NamedConstructor=Image(DOMString src)]^c
`ExtendedAttributeIdent$g `識別子を引数にとる@ `[PutForwards=name]^c
`ExtendedAttributeIdentList$g `識別子~listを引数にとる@ `[Exposed=(Window,Worker)]^c

この仕様は、~JS言語束縛に適用し得る,種々の拡張属性を定義する。 それらについては `es-extended-attributes$sec にて述べる。 各~拡張属性~定義において、上に挙げたどの形が許容されるかについて言明される。 ◎ This specification defines a number of extended attributes that are applicable to the ECMAScript language binding, which are described in section 4.3. Each extended attribute definition will state which of the above six forms are allowed.

-ExtendedAttributeList -ExtendedAttributes -ExtendedAttribute -ExtendedAttributeRest -ExtendedAttributeInner -Other -OtherOrComma -IdentifierList -Identifiers -ExtendedAttributeNoArgs -ExtendedAttributeArgList -ExtendedAttributeIdent -ExtendedAttributeIdentList -ExtendedAttributeNamedArgList

4. ~JS言語束縛

この節では、 `idl$sec にて定義された~IDLで記される`定義$~JS言語~仕様 第 6 版 `ECMA-262$r により定義される~JSの中の個々の構成子との対応を述べる。 ◎ This section describes how definitions written with the IDL defined in section 3 correspond to particular constructs in ECMAScript, as defined by the ECMAScript Language Specification 6th Edition [ECMA-262].

他から指定されない限り,この節で定義される各~objは:

  • ECMA-262 の 9.1 節, 9.3.1 節 に記述される内的~prop を持つ。 指定がある場合は、次のうち1つ以上のものが,~exotic~objに対する規則に則って再定義される: `Call^es, `Set^es, `DefineOwnProperty^es, `GetOwnProperty^es, `Delete^es, `HasInstance^es 。 ◎ Objects defined in this section have internal properties as described in ECMA-262 sections 9.1 and 9.3.1 unless otherwise specified, in which case one or more of the following are redefined in accordance with the rules for exotic objects: [[Call]], [[Set]], [[DefineOwnProperty]], [[GetOwnProperty]], [[Delete]] and [[HasInstance]].

    他の仕様は、`~ifc$の~instanceである`~platform~obj$の内的~methの定義を上書きして~MAY。 ◎ Other specifications MAY override the definitions of any internal method of a platform object that is an instance of an interface. Warning

    内的~JS~obj~methを上書きすることは、低~levelの演算であり,~objの挙動を普通の~objから違えさせ得るので、この便宜性は,保安/互換性のために必要とされない限り,利用される~SHOULD_NOT。 これは、 `Location^T ~obj と, 場合によっては `WindowProxy^T ~obj に利用されることが予期されている。 ◎ As overriding internal ECMAScript object methods is a low level operation and can result in objects that behave differently from ordinary objects, this facility SHOULD NOT be used unless necessary for security or compatibility. The expectation is that this will be used for Location objects and possibly WindowProxy objects.

  • その `Extensible^es 内的~propの値は `true^v である。 ◎ Unless otherwise specified, the [[Extensible]] internal property of objects defined in this section has the value true.
  • その `Prototype^es 内的~propは `Object^v 原型~objである。 ◎ Unless otherwise specified, the [[Prototype]] internal property of objects defined in this section is the Object prototype object.

この節にて述べる一部の~objは、 `~class文字列@ を持つものと定義される。 それは、 `Object.prototype.toString^c が返す文字列に内包される。 ~class文字列を持つ~objは、その作成-時に,その指定された文字列を値にとる,名前 `toStringTag_symbol^ ~symbolの~propを持た~MUST。 ◎ Some objects described in this section are defined to have a class string, which is the string to include in the string returned from Object.prototype.toString. If an object has a class string, then the object MUST, at the time it is created, have a property whose name is the @@toStringTag symbol and whose value is the specified string.

`toStringTag_symbol^ が { writable, enumerable, configurable } かどうかを定義するべきである。 ES6 仕様における すべての `toStringTag_symbol^ ~propは、非 writable かつ非 enumerable であり,非 configurable である。 ◎ Should define whether @@toStringTag is writable, enumerable and configurable. All @@toStringTag properties in the ES6 spec are non-writable and non-enumerable, and configurable.

`関数~obj@ であるものと定義される~objは、次の特徴を有する: ◎ If an object is defined to be a function object, then it has characteristics as follows:

  • 他から指定されない限り,その `Prototype^es 内的~propは `FunctionPrototype^ ( `ECMA-262$r 6.1.7.4 節)である。 ◎ Its [[Prototype]] internal property is %FunctionPrototype% ([ECMA-262], section 6.1.7.4) unless otherwise specified.
  • その `Get^es 内的~prop は ECMA-262 9.1.8 節 の記述に従って設定される。 ◎ Its [[Get]] internal property is set as described in ECMA-262 section 9.1.8.
  • その `Construct^es 内的~prop は ECMA-262 19.2.2.3 節 の記述に従って設定される。 ◎ Its [[Construct]] internal property is set as described in ECMA-262 section 19.2.2.3.
  • 他から指定されない限り,その @@hasInstance 内的~prop は ECMA-262 19.2.3.8 節 の記述に従って設定される。 ◎ Its @@hasInstance property is set as described in ECMA-262 section 19.2.3.8, unless otherwise specified.

上の~listは、最新の ES6 草案に沿うように更新する必要がある。 ◎ The list above needs updating for the latest ES6 draft.

この節の中の~algoは、手続きとその下位~手続き, 数学的演算, 等々の利用に関し, ECMA-262 Algorithm Conventions 節 に記述されている表記規約を利用する。 この節で参照される抽象演算: `ToBoolean$A, `ToNumber$A, `ToUint16$A, `ToInt32$A, `ToUint32$A, `ToString$A, `ToObject$A, `IsAccessorDescriptor$A, `IsDataDescriptor$A, 並びに `Type^( %x ) 記法は、 ECMA-262 6, 7 節にて定義される。 ◎ Algorithms in this section use the conventions described in ECMA-262 section 5.2, such as the use of steps and substeps, the use of mathematical operations, and so on. The ToBoolean, ToNumber, ToUint16, ToInt32, ToUint32, ToString, ToObject, IsAccessorDescriptor and IsDataDescriptor abstract operations and the Type(x) notation referenced in this section are defined in ECMA-262 sections 6 and 7.

~algoにおいて “THROW SomethingError” と記される所では、 ECMA-262 の~algoとちょうど同じ様に,新たな~JSSomethingError ~objを構築して投出することを意味する。 ◎ When an algorithm says to “throw a SomethingError” then this means to construct a new ECMAScript SomethingError object and to throw it, just as the algorithms in ECMA-262 do.

~algoの手続きは,他の~algoや抽象演算の中へ~callし得るが、それらから投出される例外は 明示的に取扱われていないことに注意。 ~algoまたは抽象演算により例外が投出され,それが~call元により明示的に取扱われない所では、~algoは終了され,その~call元の更に外へ伝播する,等々となる。 ◎ Note that algorithm steps can call in to other algorithms and abstract operations and not explicitly handle exceptions that are thrown from them. When an exception is thrown by an algorithm or abstract operation and it is not explicitly handled by the caller, then it is taken to end the algorithm and propagate out to its caller, and so on.

次の~algoを考える: ◎ Consider the following algorithm:

  1. %x := この~algoに渡された~JS値 ◎ Let x be the ECMAScript value passed in to this algorithm.
  2. %y := `ToString$A( %x ) ◎ Let y be the result of calling ToString(x).
  3. ~RET %y ◎ Return y.

`ToString$A は例外を投出し得るが(例えば~obj `({ toString: function() { throw 1 } })^c が渡されたとき),例外は上の~algoでは取扱われないので、もし投出された場合、この~algoは終了され,その例外は ~call元が在るならばその~call元に伝播する。 ◎ Since ToString can throw an exception (for example if passed the object ({ toString: function() { throw 1 } })), and the exception is not handled in the above algorithm, if one is thrown then it causes this algorithm to end and for the exception to propagate out to its caller, if there is one.

【 この訳では、原文における明示的な例外の取扱いの表記に,(いわゆる try 〜 catch 文に似た)次の記法を用いる:

~TRY: ~block1 ~CATCH: ~block2

~block2 は、 ~block1 の中で例外が投出されたとき, そのときに限り,(例外を~call元へ伝播させる代わりに)実行されるものとする。 この例外は、 ~block2 の中では, `投出された例外@ と記される。 】

4.1. ~JS環境

所与の[ `~IDL片$の集合 ]に対する~JS実装においては、それらの`~IDL片$の中の それぞれの定義に対応する,~JS~objが存在することになる。 これらの~objは `初期~obj@ と呼ばれ、次のものからなる: ◎ In an ECMAScript implementation of a given set of IDL fragments, there will exist a number of ECMAScript objects that correspond to definitions in those IDL fragments. These objects are termed the initial objects, and comprise the following:

  • `~ifc~obj$ ◎ interface objects
  • `有名~構築子$ ◎ named constructors
  • `~ifc原型~obj$ ◎ interface prototype objects
  • `有名~prop~obj$ ◎ named properties objects
  • `反復子~原型~obj$ ◎ iterator prototype objects
  • `属性~取得子$ ◎ attribute getters
  • `属性~設定子$ ◎ attribute setters
  • 演算 に対応する `Function^t ~obj ◎ the Function objects that correspond to operations
  • 文字列化子 に対応する `Function^t ~obj ◎ the Function objects that correspond to stringifiers
  • 直列化子 に対応する `Function^t ~obj ◎ the Function objects that correspond to serializers
  • 反復子 に対応する `Function^t ~obj ◎ the Function objects that correspond to iterators
  • `既定の偽装不可 valueOf 関数$ ◎ default unforgeable valueOf functions
  • `~map~size取得子$ ◎ map size getters
  • `DOMException 構築子~obj$ ◎ DOMException constructor objects
  • `DOMException 原型~obj$ ◎ DOMException prototype objects
  • `有名~prop~obj$ ◎ named properties objects

~JS大域環境 ( `ECMA-262$r 8.2 節) は、それぞれに一意な[ 各種`初期~obj$からなる集合 ]を持た~MUST。 この集合は、[ その環境のための大域~objが作成された後, かつ その環境に結付けられている~JS実行~文脈に制御が移る前 ]に作成され~MUST。 所与の大域環境に属する すべての初期~objに対し、その `Prototype^es は,同じ大域環境に属してい~MUST。 ◎ Each ECMAScript global environment ([ECMA-262], section 8.2) MUST have its own unique set of each of the initial objects, created before control enters any ECMAScript execution context associated with the environment, but after the global object for that environment is created. The [[Prototype]]s of all initial objects in a given global environment MUST come from that same global environment.

上の “大域環境に属する” という句は、所与の~objが複数の大域環境に 属する ことは,決してないことを含意する。 】

HTML ~UAにおいては、複数の frame や window が作成されたときに,複数の大域環境が存在し得る。 frame や window のそれぞれは、自身の`初期~obj$の集合を持つことになる。 次の HTML 文書の例のように: ◎ In an HTML user agent, multiple global environments can exist when multiple frames or windows are created. Each frame or window will have its own set of initial objects, which the following HTML document demonstrates:

<!DOCTYPE html>
<title>Different global environments</title>
<iframe id=a></iframe>
<script>
var iframe = document.getElementById("a");
var w = iframe.contentWindow;     // frame 内の大域~obj

Object == w.Object;       // ECMA-262 に則り, `false^v に評価される
Node == w.Node;                            // `false^v に評価される。
iframe instanceof w.Node;                  // 
iframe instanceof w.Object;                // 
iframe.appendChild instanceof Function;    // 
iframe.appendChild instanceof w.Function;  // 
</script>

他から指定されない限り、各~JS大域環境は,実装が~supportする すべての`~ifc$を `公開する@ 。 所与の~JS大域環境が公開しない~ifcは, `es-interfaces$secにて与える要件に従うとは限らない。 ◎ Unless otherwise specified, each ECMAScript global environment exposes all interfaces that the implementation supports. If a given ECMAScript global environment does not expose an interface, then the requirements given in section 4.6 are not followed for that interface.

これにより,例えば、[ Web Workers のための~JS大域環境 ]が`公開する$[ 被support~ifcの集合 ]を,[ Web ~pageのための環境 ]が公開するものと異なるようにすることも許容される。 ◎ This allows, for example, ECMAScript global environments for Web Workers to expose different sets of supported interfaces from those exposed in environments for Web pages.

これを書いている時点では,~JS仕様は それを反映していないが、どの~JS~objにも`~Realm$が結付けられ~MUST — この~Realmを指して, ~objが `属する~Realm@† という。

【† 日本語表現の都合により,この訳では “属する” という句を用いることにする。 】

各~objと~Realmを結付ける仕組みは、今の所,策定中にあるが:

  • `~platform~obj$については、それが`属する~Realm$は,その~objに`関連する~Realm$に等しい。
  • 非~exotic関数~obj(すなわち,~callable~proxyでも~bindされた関数でもない)についても、それが`属する~Realm$は,その関数~objの `Realm^es 内的~slotの値に等しい。
◎ Although at the time of this writing the ECMAScript specification does not reflect this, every ECMAScript object must have an associated Realm. The mechanisms for associating objects with Realms are, for now, underspecified. However, we note that in the case of platform objects, the associated Realm is equal to the object's relevant Realm, and for non-exotic function objects (i.e. not callable proxies, and not bound functions) the associated Realm is equal to the value of the function object's [[Realm]] internal slot.

4.2. ~JS型への対応関係

この節では、~IDLにおける各~型が,~JSにおける型へ どのように~~対応付けられるかについて述べる。 ◎ This section describes how types in the IDL map to types in ECMAScript.

以下の各~下位~節では、所与の[ ~IDL型の値 ]が,~JSの中ではどのように表現されるかを述べる。 各種~IDL型に対し、その型を期待する`~platform~obj$に~JS値が渡された際に ~IDL値へ変換される 方法, および その型の~IDL値が~platform~objから返される際に ~JS値へ変換される 方法が述べられる。 ◎ Each sub-section below describes how values of a given IDL type are represented in ECMAScript. For each IDL type, it is described how ECMAScript values are converted to an IDL value when passed to a platform object expecting that type, and how IDL values of that type are converted to ECMAScript values when returned from a platform object.

4.2.1. `any^T

~IDL `any$T 型は、他のすべての~IDL型の和集合なので,どの~JS値~型にも対応し得る。 ◎ Since the IDL any type is the union of all other IDL types, it can correspond to any ECMAScript value type.

~JS値から~IDL `any$T 値への`toIDL^は、 ~JS値の型に応じて次のようになる: ◎ How to convert an ECMAScript value to an IDL any value depends on the type of the ECMAScript value:

`undefined^v◎The undefined value
~JS `undefined^v 値を表現する特別な~objへの `object$T 参照 ◎ The IDL value is an object reference to a special object that represents the ECMAScript undefined value.
`null^v◎The null value
`null^V `object$T​? 参照 ◎ The IDL value is the null object? reference.
`Boolean^t◎A Boolean value
同じ真偽~値を表現する `boolean$T 値 ◎ The IDL value is the boolean value that represents the same truth value.
`Number^t◎A Number value
`es-unrestricted-double$sec による,[ `Number^t から~IDL `unrestricted double$T 値への変換-規則 ]に従って得られる値 ◎ The IDL value is that which is obtained by following the rules for converting the Number to an IDL unrestricted double value, as described in section 4.2.15, below.
`String^t◎A String value
`es-DOMString$sec による,[ `String^v から `DOMString$T 値への変換-規則 ]に従って得られる値 ◎ The IDL value is that which is obtained by following the rules for converting the String to an IDL DOMString value, as described in section 4.2.16, below.
`object^t◎An object value
同じ~objを参照する `object$T 値 ◎ The IDL value is an object value that references the same object.

~IDL `any$T 値 %V は,次のように~JS値へ`toES^される: %V が[ ~JS `undefined^v 値を表現する特別な~objへの `object$T 参照 ]ならば、~JS `undefined^v 値に変換される。 他の場合、この節の残りで述べられる, %V の`固有型$を変換するための規則に従う。 ◎ An IDL any value is converted to an ECMAScript value as follows. If the value is an object reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, the rules for converting the specific type of the IDL any value as described in the remainder of this section are performed.

4.2.2. `void^T

`void$T が~IDLに現れ得る唯一の場所は、`演算$の`返値型$である。 [ ~IDLにおいて `void$T 返値型が指定されている演算 ]を実装する[ `~platform~obj$上の関数 ]は、 `undefined^v 値を返さ~MUST。 ◎ The only place that the void type may appear in IDL is as the return type of an operation. Functions on platform objects that implement an operation whose IDL specifies a void return type MUST return the undefined value.

[ ~IDLにおいて `void$T 返値型が指定されている演算 ]を実装する~JS関数は、どのような値を返しても~MAY(破棄されることになる)。 ◎ ECMAScript functions that implement an operation whose IDL specifies a void return type MAY return any value, which will be discarded.

4.2.3. `boolean^T

次の~algoにより, ~JS値 %V は~IDL `boolean$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL boolean value by running the following algorithm:

  1. %x := `ToBoolean$A( %V ) の算出-結果 ◎ Let x be the result of computing ToBoolean(V).
  2. ~RET [ ~JS `Boolean^t 値 %x ]と同じ真偽~値を表現する~IDL `boolean$T 値 ◎ Return the IDL boolean value that is the one that represents the same truth value as the ECMAScript Boolean value x.

~IDL `boolean$T 値[ `true^V/`false^V ]は,~JS[ `true^v/`false^v ]値に`toES^される。 ◎ The IDL boolean value true is converted to the ECMAScript true value and the IDL boolean value false is converted to the ECMAScript false value.

4.2.4 〜 11. 整数~型

【 この訳では、原文の次に挙げる各~節の内容 — ~JS値 から各種~IDL整数~型 値への変換, およびその逆の変換の定義 — の重複する記述を集約して,一括して与える。 】

  • 4.2.4. `byte^T
  • 4.2.5. `octet^T
  • 4.2.6. `short^T
  • 4.2.7. `unsigned short^T
  • 4.2.8. `long^T
  • 4.2.9. `unsigned long^T
  • 4.2.10. `long long^T
  • 4.2.11. `unsigned long long^T

この節を通して,記号 %T は、任意に与えられた~~特定の~IDL`整数~型$を表すものとする。

この節の記号 %MIN, %MAX, %N, %signed は、 %T に応じて,次の表で与えられる値を表すものとする:

%T %MIN %MAX %N %signed
`byte$T −2`7^sup 2`7^sup − 1 8 ~T
`octet$T 0 2`8^sup − 1 8 ~F
`short$T −2`15^sup 2`15^sup − 1 16 ~T
`unsigned short$T 0 2`16^sup − 1 16 ~F
`long$T −2`31^sup 2`31^sup − 1 32 ~T
`unsigned long$T 0 2`32^sup − 1 32 ~F
`long long$T −2`53^sup + 1 2`53^sup − 1 64 ~T
`unsigned long long$T 0 2`53^sup − 1 64 ~F

【 `long long^T, `unsigned long long^T の %MIN, %MAX が, 2 の 53 乗で~~制限されていることに注意。 】

次の~algoにより,~JS値 %V は~IDL`整数~型$ %T の値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL _T_ value by running the following algorithm:

  1. %x :← `ToNumber$A( %V ) ◎ Initialize x to ToNumber(V).
  2. ~IF ~IDL値への変換は, `EnforceRange$x 注釈付きの[ `属性$に代入される/ `演算$の引数に渡される/ `辞書~mb$の値に利用される ]ことにより遂行されている ⇒ ◎ If the conversion to an IDL value is being performed due to any of the following: • V is being assigned to an attribute annotated with the [EnforceRange] extended attribute, • V is being passed as an operation argument annotated with the [EnforceRange] extended attribute, or • V is being used as the value of a dictionary member annotated with the [EnforceRange] extended attribute, then:

    1. ~IF %x ~IN { `NaN^v, +∞, −∞ } ~THEN ~THROW `TypeError^t ◎ If x is NaN, +∞, or −∞, then throw a TypeError.
    2. %x ← sign(%x) × floor(abs(%x)) ◎ Set x to sign(x) * floor(abs(x)).
    3. ~IF[ %x < %MIN ]~OR[ %x > %MAX ] ~THEN ~THROW `TypeError^t ◎ If x < −_MIN_ or x > _MAX_, then throw a TypeError.
  3. ~ELIF[ %x ~NEQ `NaN^v ]~AND[ ~IDL値への変換は, `Clamp$x 注釈付きの[ `属性$に代入される/ `演算$の引数に渡される/ `辞書~mb$の値に利用される ]ことにより遂行されている ] ⇒ ◎ If x is not NaN and the conversion to an IDL value is being performed due to any of the following: • V is being assigned to an attribute annotated with the [Clamp] extended attribute, • V is being passed as an operation argument annotated with the [Clamp] extended attribute, or • V is being used as the value of a dictionary member annotated with the [Clamp] extended attribute, then:

    1. %x ← min(max(%x, %MIN), %MAX) ◎ Set x to min(max(x, _MIN_), _MAX_).
    2. %x ← %x を最も近い整数に丸めた結果(2つの整数と等距離にある場合は偶数を選び,−0 より +0 の方を選ぶ) ◎ Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
  4. ~ELSE ⇒

    1. ~IF %x ~IN { `NaN^v, +0, −0, +∞, −∞ } ~THEN ~RET 0 を表現する 型 %T の~IDL値 ◎ If x is NaN, +0, −0, +∞, or −∞, then return the IDL _T_ value that represents 0.
    2. %x ← %x modulo 2%N ◎ Set x to x modulo 2_N_.
    3. ~IF[ %signed ~EQ ~T ]~AND[ %x ≥ 2%N − 1 ] ~THEN %x ← %x − 2%N ◎ If x is greater than or equal to 2_N_-1, then set x to x − 2_N_.

    【 %T が `unsigned short$T / `long$T / `unsigned long$T ならば,この下位手続きの~~処理はそれぞれ `ToUint16$A / `ToInt32$A / `ToUint32$A に一致する。 】

  5. ~RET %x と同じ実数~値を表現する,型 %T の~IDL値 ◎ Return the IDL _T_ value that represents the same numeric value as x.

~IDL`整数~型$ %T の値 %V を~JS値に`toES^した結果は, %T に応じて次で与えられる: ◎ The result of converting an IDL _T_ value to an ECMAScript value is a ...

`long long$T
`unsigned long long$T
%V に`最近数値^を表現する `Number^t 値。 %V が範囲 [%MIN, %MAX] に入るならば、その値 は %V と正確に同じ値を表現できることになる。 ◎ Number value that represents the closest numeric value to _T_, choosing the numeric value with an even significand if there are two equally close values ([ECMA-262], section 6.1.6). If _T_ is in the range [_MIN_, _MAX_], then the Number will be able to represent exactly the same value as _T_.
他の整数~型
%V と同じ実数~値を表現する `Number^t 値。 その値は 範囲 [%MIN, %MAX] の整数になる。 ◎ Number that represents the same numeric value as the IDL _T_ value. The Number value will be an integer in the range [_MIN_, _MAX_].

4.2.12. `float^T

次の~algoにより, ~JS値 %V は~IDL `float$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL float value by running the following algorithm:

  1. %x := `ToNumber$A( %V ) ◎ Let x be ToNumber(V).
  2. ~IF %x ~IN { `NaN^v, `+Infinity^v, `−Infinity^v } ~THEN ~THROW `TypeError^t ◎ If x is NaN, +Infinity or −Infinity, then throw a TypeError.
  3. %S := [ −0 を除く有限 IEEE 754 単精度 浮動小数点~値の集合に,2つの特別な値{ 2`128^sup, −2`128^sup } を追加した集合 ] ◎ Let S be the set of finite IEEE 754 single-precision floating point values except −0, but with two special values added: 2^128 and −2^128.
  4. %y := [ %S の中で %x に`最近数値^ ] (この目的においては,2つの特別な値 2`128^sup, −2`128^sup の仮数は偶数と見なされる。) ◎ Let y be the number in S that is closest to x, selecting the number with an even significand if there are two equally close values ([ECMA-262], section 8.5). (The two special values 2^128 and −2^128 are considered to have even significands for this purpose.)
  5. ~IF %y ~IN { 2`128^sup, −2`128^sup } ~THEN ~THROW `TypeError^t ◎ If y is 2^128 or −2^128, then throw a TypeError.
  6. ~IF[ %y ~EQ +0 ]~AND[ %x < 0 ] ~THEN ~RET −0 ◎ If y is +0 and x is negative, return −0.
  7. ~RET %y ◎ Return y.

~IDL `float$T 値を~JS値に`toES^した結果は、その ~IDL値と同じ実数~値を表現する `Number^t 値になる。 ◎ The result of converting an IDL float value to an ECMAScript value is the Number value that represents the same numeric value as the IDL float value.

4.2.13. `unrestricted float^T

次の~algoにより, ~JS値 %V は~IDL `unrestricted float$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL unrestricted float value by running the following algorithm:

  1. ~IF %x ~EQ `NaN^v ~THEN ~RET ~bit~pattern 0x7fc00000 の IEEE 754 NaN 値 `IEEE-754$r を表現する~IDL `unrestricted float$T 値 ◎ If x is NaN, then return the IDL unrestricted float value that represents the IEEE 754 NaN value with the bit pattern 0x7fc00000 [IEEE-754].
  2. ~IF %y ~EQ 2`128^sup ~THEN ~RET +∞ ◎ If y is 2^128, return +∞.
  3. ~IF %y ~EQ −2`128^sup ~THEN ~RET −∞ ◎ If y is −2^128, return −∞.

~JS `NaN^v 値は唯1個しかないので,特定0の単精度 IEEE 754 NaN 値に正準化されなければならない。 上に示された NaN 値は、単純に,その~bit~patternが無符号 32 ~bit整数に解釈されたときに最低~値の quiet NaN になることから,選ばれている。 ◎ Since there is only a single ECMAScript NaN value, it must be canonicalized to a particular single precision IEEE 754 NaN value. The NaN value mentioned above is chosen simply because it is the quiet NaN with the lowest value when its bit pattern is interpreted as an unsigned 32 bit integer.

~IDL `unrestricted float$T 値を~JS値に`toES^した結果は、次の `Number^t になる: ◎ The result of converting an IDL unrestricted float value to an ECMAScript value is a Number:

  • その~IDL値 ~EQ NaN ならば `NaN^v ◎ If the IDL unrestricted float value is a NaN, then the Number value is NaN.
  • 他の場合,その~IDL値と同じ実数~値を表現する(~~唯一の) `Number^t 値。 ◎ Otherwise, the Number value is the one that represents the same numeric value as the IDL unrestricted float value.

4.2.14. `double^T

次の~algoにより, ~JS値 %V は~IDL `double$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL double value by running the following algorithm:

  1. ~IF %x ~IN { `NaN^v, `+Infinity^v, `−Infinity^v } ~THEN ~THROW `TypeError^t ◎ If x is NaN, +Infinity or −Infinity, then throw a TypeError.
  2. ~RET %x と同じ実数~値を持つ~IDL `double$T 値 ◎ Return the IDL double value that has the same numeric value as x.

~IDL `double$T 値を~JS値に`toES^した結果は、その ~IDL値と同じ実数~値を表現する `Number^t 値になる。 ◎ The result of converting an IDL double value to an ECMAScript value is the Number value that represents the same numeric value as the IDL double value.

4.2.15. `unrestricted double^T

次の~algoにより, ~JS値 %V は~IDL `unrestricted double$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL unrestricted double value by running the following algorithm:

  1. ~IF %x ~EQ `NaN^v ~THEN ~RET ~bit~pattern 0x7ff8000000000000 の IEEE 754 NaN 値 `IEEE-754$r を表現する~IDL `unrestricted double$T 値 ◎ If x is NaN, then return the IDL unrestricted double value that represents the IEEE 754 NaN value with the bit pattern 0x7ff8000000000000 [IEEE-754].
  2. ~RET %x と同じ実数~値を持つ~IDL `unrestricted double$T 値 ◎ Return the IDL unrestricted double value that has the same numeric value as x.

~JS `NaN^v 値は唯1個しかないので,特定0の倍精度 IEEE 754 NaN 値に正準化されなければならない。 上に示された NaN 値は、単純に,その~bit~patternが無符号 64 ~bit整数に解釈されたときに最低~値の quiet NaN になることから,選ばれている。 ◎ Since there is only a single ECMAScript NaN value, it must be canonicalized to a particular double precision IEEE 754 NaN value. The NaN value mentioned above is chosen simply because it is the quiet NaN with the lowest value when its bit pattern is interpreted as an unsigned 64 bit integer.

~IDL `unrestricted double$T 値を~JS値に`toES^した結果は、次の `Number^t になる: ◎ The result of converting an IDL unrestricted double value to an ECMAScript value is a Number:

  • その~IDL値 ~EQ NaN ならば `NaN^v 。 ◎ If the IDL unrestricted double value is a NaN, then the Number value is NaN.
  • 他の場合,その~IDL値と同じ実数~値を表現する(~~唯一の) `Number^t 値。 ◎ Otherwise, the Number value is the one that represents the same numeric value as the IDL unrestricted double value.

4.2.16. `DOMString^T

次の~algoにより, ~JS値 %V は~IDL `DOMString$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL DOMString value by running the following algorithm:

  1. ~IF[ %V ~EQ `null^v ]~AND[ ~IDL値への変換は, [TreatNullAs=EmptyString] 注釈付きの[ `演算$の引数に渡される / `属性$に代入される / 演算の`利用者~obj$実装から返される / 属性の`利用者~obj$実装から返される ]ことにより遂行されている ] ~THEN ~RET 空~文字列を表現する `DOMString$T 値 ◎ If V is null and the conversion to an IDL value is being performed due to any of the following: • V is being passed as an operation argument that is annotated with [TreatNullAs=EmptyString], • V is being assigned to an attribute annotated with [TreatNullAs=EmptyString], • V is being returned from a user object implementation of an operation annotated with [TreatNullAs=EmptyString], or • V is being returned from a user object implementation of an attribute annotated with [TreatNullAs=EmptyString], ◎ then return the DOMString value that represents the empty string.
  2. %x := `ToString$A( %V ) ◎ Let x be ToString(V).
  3. ~RET [ その~JS `String^t 値 %x が表現するものと同じ,符号単位の並び ]を表現する~IDL `DOMString$T 値 ◎ Return the IDL DOMString value that represents the same sequence of code units as the one the ECMAScript String value x represents.

~IDL `DOMString$T 値を~JS値に`toES^した結果は、 その~IDL `DOMString$T が表現するものと同じ, `符号単位$の並びを表現する `String^t 値になる。 ◎ The result of converting an IDL DOMString value to an ECMAScript value is the String value that represents the same sequence of code units that the IDL DOMString represents.

4.2.17. `ByteString^T

次の~algoにより, ~JS値 %V は~IDL `ByteString$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL ByteString value by running the following algorithm:

  1. %x := `ToString$A( %V ) ◎ Let x be ToString(V).
  2. ~IF %x の中に 値 > 255 なる 要素 がある ~THEN ~THROW `TypeError^t ◎ If the value of any element of x is greater than 255, then throw a TypeError.
  3. ~RET [[ 各~要素の値 ← %x の対応する要素の値 ]にされた, 長さ ~EQ %x の長さ ]の~IDL `ByteString$T 値 ◎ Return an IDL ByteString value whose length is the length of x, and where the value of each element is the value of the corresponding element of x.

~IDL `ByteString$T 値 %V を~JS値に`toES^した結果は、[[ 各~要素の値 ← %V の対応する要素の値 ]にされた, 長さ ~EQ %V の長さ ]の `String^t 値になる。 ◎ The result of converting an IDL ByteString value to an ECMAScript value is a String value whose length is the length of the ByteString, and the value of each element of which is the value of the corresponding element of the ByteString.

4.2.18. `USVString^T

次の~algoにより, ~JS値 %V は~IDL `USVString$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL USVString value by running the following algorithm:

  1. %string := %V を `DOMString$T に`toIDL^した結果 ◎ Let string be the result of converting V to a DOMString.
  2. ~RET %string を `Unicode ~scalar値~列に変換-$した結果の~IDL `USVString$T 値 ◎ Return an IDL USVString value that is the result of converting string to a sequence of Unicode scalar values.

次の~algoにより, ~IDL `USVString$T 値 %V は~JS値に`toES^される: ◎ An IDL USVString value is converted to an ECMAScript value by running the following algorithm:

  1. %scalarValues := `USVString$T が表現する `Unicode ~scalar値$の並び ◎ Let scalarValues be the sequence of Unicode scalar values the USVString represents.
  2. %string := %scalarValues を UTF-16 に符号化した結果の`符号単位$の並び ◎ Let string be the sequence of code units that results from encoding scalarValues in UTF-16.
  3. ~RET %string と同じ`符号単位$の並びを表現する `String^t 値 ◎ Return the String value that represents the same sequence of code units as string.

4.2.19. `object^T

~IDL `object$T 値は ~JS `Object^t 値により表現される。 ◎ IDL object values are represented by ECMAScript Object values.

次の~algoにより, ~JS値 %V は~IDL `object$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL object value by running the following algorithm:

  1. ~IF `Type^( %V ) ~NEQ `Object^t ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Object, then throw a TypeError.
  2. ~RET %V と同じ~objを参照する~IDL `object$T 値 ◎ Return the IDL object value that is a reference to the same object as V.

~IDL `object$T 値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Object^t 値になる。 ◎ The result of converting an IDL object value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL object represents.

4.2.20. ~ifc型

~IDL`~ifc型$の値は ~JS[ `Object^t, または `Function^t ]値により表現される。 ◎ IDL interface type values are represented by ECMAScript Object or Function values.

次の~algoにより, ~JS値 %V は~IDL`~ifc型$の値に`toIDL^される(以下では %I をその`~ifc$とする): ◎ An ECMAScript value V is converted to an IDL interface type value by running the following algorithm (where I is the interface):

  1. ~IF %V は %I を実装する`~platform~obj$である ~THEN ~RET その~platform~objへの参照を表現する,~IDL`~ifc型$の値 ◎ If V is a platform object that implements I, then return the IDL interface type value that represents a reference to that platform object.
  2. ~IF %V は[ `es-user-objects$sec の規則に従って %I を実装する ]ものと見なされる`利用者~obj$である ~THEN ~RET その利用者~objへの参照を表現し, `呼戻~文脈$として`~incumbent設定群~obj$ `HTML$r を伴う, ~IDL`~ifc型$の値 ◎ If V is a user object that is considered to implement I according to the rules in section 4.9, then return the IDL interface type value that represents a reference to that user object, with the incumbent settings object as the callback context. [HTML]
  3. ~THROW `TypeError^t ◎ Throw a TypeError.

~IDL`~ifc型$の値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Object^t 値になる。 ◎ The result of converting an IDL interface type value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL interface type value represents.

4.2.21. 辞書~型

~IDL`辞書~型$の値は ~JS `Object^t 値により表現される。 その~obj(またはその原型鎖)上の~propが`辞書~mb$に対応する。 ◎ IDL dictionary type values are represented by ECMAScript Object values. Properties on the object (or its prototype chain) correspond to dictionary members.

次の~algoにより, ~JS値 %V は~IDL`辞書$ %D の型の値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL dictionary type value by running the following algorithm (where D is the dictionary):

  1. ~IF `Type^( %V ) ~NIN { `Undefined^t, `Null^t, `Object^t } ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Undefined, Null or Object, then throw a TypeError.
  2. ~IF %V は ~native `RegExp^t ~objである ~THEN ~THROW `TypeError^t ◎ If V is a native RegExp object, then throw a TypeError.
  3. %dict := 型 %D の空の辞書~値(初期~時にはどの`辞書~mb$も`不在$と見なされる) ◎ Let dict be an empty dictionary value of type D; every dictionary member is initially considered to be not present.
  4. %dictionaries := %D および %D のすべての`被継承~辞書$を,先祖から先に,継承-順に並べた~list ◎ Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, in order from least to most derived.
  5. ~FOR %dictionaries 内の~EACH ( 辞書 %dictionary ) に対し,順に: ◎ For each dictionary dictionary in dictionaries, in order:

    1. ~FOR %dictionary 上に宣言されている~EACH ( 辞書~mb %member ) に対し,辞書式~順序で: ◎ For each dictionary member member declared on dictionary, in lexicographical order:

      1. %key := %member の`識別子$ ◎ Let key be the identifier of member.
      2. %value := `Type^( %V ) に応じて,次で与えられる~JS値: ◎ Let value be an ECMAScript value, depending on Type(V):

        `Undefined^t
        `Null^t
        `undefined^v ◎ value is undefined.
        その他◎anything else
        ~prop名 %key により, %V 上の `Get^es 内的~methを~callした結果 ◎ value is the result of calling the [[Get]] internal method on V with property name key.
      3. ~IF %value ~NEQ `undefined^v ~THEN %idlValue := %value を %member に宣言されている型の~IDL値に`toIDL^した結果 ◎ If value is not undefined, then: • Let idlValue be the result of converting value to an IDL value whose type is the type member is declared to be of. • Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.
      4. ~ELIF %member は `辞書既定値^ %d を持つ ~THEN %idlValue := %d ◎ Otherwise, if value is undefined but the dictionary member has a default value, then: • Let idlValue be the dictionary member’s default value. • Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.
      5. ~ELIF %member は `必須~辞書~mb$である ~THEN ~THROW `TypeError^t ◎ Otherwise, if value is undefined and the dictionary member is a required dictionary member, then throw a TypeError.
      6. ~ELSE ~THEN ~CONTINUE ◎ ↑
      7. %dict 上の ~key名 %key の辞書~mbの値 ← %idlValue (この辞書~mbは`在する$ものと見なされるようになる) ◎ ↑
  6. ~RET %dict ◎ Return dict.

`辞書~mb$が~JS~obj上で検索される順序は、~objの~prop列挙~順序と同じになるとは限らない。 ◎ The order that dictionary members are looked up on the ECMAScript object are not necessarily the same as the object’s property enumeration order.

次の~algoにより, ~IDL辞書 %D 型の値 %V は~JS `Object^t 値に`toES^される: ◎ An IDL dictionary value V is converted to an ECMAScript Object value by running the following algorithm (where D is the dictionary):

  1. %O := 式 `({})^c で作成されるものと同じ,新たな `Object^t 値 ◎ Let O be a new Object value created as if by the expression ({}).
      1. ~IF 名前 %key の辞書~mbが %V 内に`在する$ ⇒ ◎ If the dictionary member named key is present in V, then:

        1. %idlValue := %V 上の %member の値 ◎ Let idlValue be the value of member on V.
        2. %value := %idlValue を~JS値に`toES^した結果 ◎ Let value be the result of converting idlValue to an ECMAScript value.
        3. `CreateDataProperty$A( %O, %key, %value ) を~callする ◎ Call CreateDataProperty(O, key, value.
  2. ~RET %O ◎ Return O.

4.2.22. 列挙~型

~IDL`列挙~型$の値は ~JS `String^t 値により表現される。 ◎ IDL enumeration types are represented by ECMAScript String values.

次の~algoにより, ~JS値 %V は ~IDL`列挙$ %E の型の値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL enumeration type value as follows (where E is the enumeration):

  1. %S := `ToString$A( %V ) ◎ Let S be the result of calling ToString(V).
  2. ~IF %S は %E の`列挙~値$のいずれでもない ~THEN ~THROW `TypeError^t ◎ If S is not one of E’s enumeration values, then throw a TypeError.
  3. ~RET 型 %E の, %S に等しい列挙~値 ◎ Return the enumeration value of type E that is equal to S.

~IDL`列挙$型の値を~JS値に`toES^した結果は、[ その`列挙~値$と同じ`符号単位$の並び ]を表現する `String^t 値になる。 ◎ The result of converting an IDL enumeration type value to an ECMAScript value is the String value that represents the same sequence of code units as the enumeration value.

4.2.23. 呼戻~関数~型

~IDL`呼戻~関数~型$の値は~JS `Function^t ~objにより表現される。 ただし, `TreatNonObjectAsNull$x の場合は、任意の~objをとり得る。 ◎ IDL callback function types are represented by ECMAScript Function objects, except in the [TreatNonObjectAsNull] case, when they can be any object.

次の~algoにより, ~JS値 %V は~IDL`呼戻~関数~型$の値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL callback function type value by running the following algorithm:

  1. ~IF[ `IsCallable$A( %V ) ~EQ ~false ]~AND [ ~IDL値への変換は[ `~nullable$ `呼戻~関数$型 ~AND `TreatNonObjectAsNull$x 注釈付き ]である`属性$への代入-により,遂行されてはいない ] ~THEN ~THROW `TypeError^t ◎ If the result of calling IsCallable(V) is false and the conversion to an IDL value is not being performed due to V being assigned to an attribute whose type is a nullable callback function that is annotated with [TreatNonObjectAsNull], then throw a TypeError.
  2. ~RET %V が表現するものと同じ~objを表現し, `呼戻~文脈$として`~incumbent設定群~obj$ `HTML$r を伴う, ~IDL`呼戻~関数~型$の値 ◎ Return the IDL callback function type value that represents a reference to the same object that V represents, with the incumbent settings object as the callback context. [HTML].

~IDL`呼戻~関数~型$の値を~JS値に`toES^した結果は、その`呼戻~関数~型$の値が表現するものと同じ~objへの参照になる。 ◎ The result of converting an IDL callback function type value to an ECMAScript value is a reference to the same object that the IDL callback function type value represents.

4.2.24. ~nullable型 — `~varT?^T

~IDL`~nullable型$の値は、その`内縁~型$に対応する~JS型の値か, または ~JS `null^v 値により表現される。 ◎ IDL nullable type values are represented by values of either the ECMAScript type corresponding to the inner IDL type, or the ECMAScript null value.

この節を通して、 `~varT?^T は,`内縁~型$が %T である~IDL`~nullable型$を表す。

次の~algoにより, ~JS値 %V は `~varT?^T 型の値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL nullable type T? value (where T is the inner type) as follows:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~AND [ %V から~IDL値への変換は[ `~nullable$`呼戻~関数$型 ~AND `TreatNonObjectAsNull$x 注釈付き ]である`属性$への代入-により遂行されている ] ~THEN ~RET 型 `~varT?^T の値 `null^V ◎ If Type(V) is not Object, and the conversion to an IDL value is being performed due to V being assigned to an attribute whose type is a nullable callback function that is annotated with [TreatNonObjectAsNull], then return the IDL nullable type T? value null.
  2. ~IF %V ~IN { `null^v, `undefined^v } ~THEN ~RET 型 `~varT?^T の値 `null^V ◎ Otherwise, if V is null or undefined, then return the IDL nullable type T? value null.
  3. ~RET %V を`内縁~型$ %T に対する規則に従って`toIDL^した結果 ◎ Otherwise, return the result of converting V using the rules for the inner IDL type T.

型 `~varT?^T の~IDL値 %V を~JS値に`toES^した結果は、[ %V ~EQ `null^V ならば `null^v / ~ELSE_ %V を型 %T の値として~JS値に`toES^した結果 ]になる。 ◎ The result of converting an IDL nullable type value to an ECMAScript value is: • If the IDL nullable type T? value is null, then the ECMAScript value is null. • Otherwise, the ECMAScript value is the result of converting the IDL nullable type value to the inner IDL type T.

4.2.25. 連列 — `sequence<~varT>^T

~IDL `sequence_T^ 値は ~JS `Array^t 値により表現される。 ◎ IDL sequence<T> values are represented by ECMAScript Array values.

次の~algoにより, ~JS値 %V は~IDL `sequence_T^ 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL sequence<T> value as follows:

  1. ~IF %V は ~objでない ~THEN ~THROW `TypeError^t ◎ If V is not an object, throw a TypeError.
  2. ~IF %V は ~native `RegExp^t ~objである ~THEN ~THROW `TypeError^t ◎ If V is a native RegExp object, throw a TypeError.
  3. %method := `GetMethod$A( %V, `iterator_symbol^ ) の結果 ◎ Let method be the result of GetMethod(V, @@iterator).
  4. `ReturnIfAbrupt$A( %method ) ◎ ReturnIfAbrupt(method).
  5. ~IF %method ~EQ `undefined^v ~THEN ~THROW `TypeError^t ◎ If method is undefined, throw a TypeError.
  6. %V, %method から型 `sequence_T^ の`連列~値を作成-$した結果 ◎ Return the result of creating a sequence of type sequence<T> from V and method.

次の~algoにより,型 `sequence_T^ の~IDL連列~値 %S は ~JS `Array^t ~objに`toES^される: ◎ An IDL sequence value S of type sequence<T> is converted to an ECMAScript Array object as follows:

  1. %n := %S の長さ ◎ Let n be the length of S.
  2. %A := 式 `[]^c で作成されるものと同じ,新たな `Array^t ~obj ◎ Let A be a new Array object created as if by the expression [].
  3. %i :← 0 ◎ Initialize i to be 0.
    1. %V := %S 内の~index %i に位置する値 ◎ Let V be the value in S at index i.
    2. %E := %V を~JS値に`toES^した結果 ◎ Let E be the result of converting V to an ECMAScript value.
    3. %P := `ToString$A( %i ) ◎ Let P be the result of calling ToString(i).
    4. `CreateDataProperty$A( %A, %P, %E ) を~callする ◎ Call CreateDataProperty(A, P, E).
  4. ~RET %A ◎ Return A.
4.2.25.1. 可反復から連列を作成する

所与の[ 可反復 %iterable, 反復子~取得子 %method ]から 型 `sequence_T^ の~IDL値を作成するときは,次の手続きを遂行する: ◎ To create an IDL value of type sequence<T> given an iterable iterable and an iterator getter method, perform the following steps:

  1. %iter := `GetIterator$A(%iterable, %method) ◎ Let iter be GetIterator(iterable, method).
  2. `ReturnIfAbrupt$A( %iter ) ◎ ReturnIfAbrupt(iter).
  3. %i :← 0 ◎ Initialize i to be 0.
  4. ~WHILE 無条件: ◎ Repeat

    1. %next := `IteratorStep$A( %iter ) ◎ Let next be IteratorStep(iter).
    2. `ReturnIfAbrupt$A( %next ) ◎ ReturnIfAbrupt(next).
    3. ~IF %next ~EQ `false^v ~THEN ~RET ~index %j に位置する要素の値が %S%j で, 長さ %i の,型 `sequence_T^ の~IDL連列~値 ◎ If next is false, then return an IDL sequence value of type sequence<T> of length i, where the value of the element at index j is Sj.
    4. %nextItem := `IteratorValue$A( %next ) ◎ Let nextItem be IteratorValue(next).
    5. `ReturnIfAbrupt$A( %nextItem ) ◎ ReturnIfAbrupt(nextItem).
    6. %S%i :← %nextItem を型 %T の~IDL値に`toIDL^した結果 ◎ Initialize Si to the result of converting nextItem to an IDL value of type T.
    7. %i ← %i + 1 ◎ Set i to i + 1.

次の`~ifc$は 連列~型の引数を伴う`演算$と伴に 連列~型の`属性$を定義する。 ◎ The following interface defines an attribute of a sequence type as well as an operation with an argument of a sequence type.

interface Canvas {

  sequence<DOMString> getSupportedImageCodecs();

  void drawPolygon(sequence<double> coordinates);
  sequence<double> getLastDrawnPolygon();

  // ...
};

この~ifcの~JS実装においては、型[ `String^t / `Number^t ]の要素からなる `Array^t ~objが,それぞれ[ `sequence<DOMString>^T / `sequence<double>^T ]の表現-に利用される。 この `Array^t ~objは実質的には値渡しであり、 `getSupportedImageCodecs()^c 関数が~callされる度に,新たな `Array^t が返され、 `Array^t が `drawPolygon^c に渡されたときは常に,その参照は~call完了-後には保有されないことになる。 ◎ In an ECMAScript implementation of this interface, an Array object with elements of type String is used to represent a sequence<DOMString>, while an Array with elements of type Number represents a sequence<double>. The Array objects are effectively passed by value; every time the getSupportedImageCodecs() function is called a new Array is returned, and whenever an Array is passed to drawPolygon no reference will be kept after the call completes.

/* `Canvas^T の~instanceを得る。
   `getSupportedImageCodecs()^c は、2個の `DOMString^T 値
     `image/png^l, `image/svg+xml^l
   からなる連列を返すものとする。 */
var canvas = getCanvas();

// 長さ 2 の `Array^t ~obj。
var supportedImageCodecs = canvas.getSupportedImageCodecs();

// `image/png^l に評価される。
supportedImageCodecs[0];

/* `canvas.getSupportedImageCodecs()^c が~callされる度に,新たな
   `Array^t object が返される。したがって,返された `Array^t を改変しても,
  後続の関数~callで返される値には影響しないことになる。 */
supportedImageCodecs[0] = `image/jpeg^l;

// 
canvas.getSupportedImageCodecs()[0];

// 各~callで新たな `Array^t ~objが返されるので、これは `false^v に評価される。
canvas.getSupportedImageCodecs() == canvas.getSupportedImageCodecs();


// 実数~値の `Array^t は...
var a = [0, 0, 100, 0, 50, 62.5];

// ...は `sequence<double>^T を期待する~platform~objに渡すことができる
canvas.drawPolygon(a);

/* 各~要素は最初に `ToNumber$A() の~callにより, `double^T に変換される。
   したがって,次の~callは `drawPolygon()^c が返る前に
   `hi^l が alert されることを除き,前のものと等価になる。 */
a = [
    false,
    '',
    { valueOf: function() { alert('hi'); return 100; } },
    0,
    '50',
    new Number(62.5)
];
canvas.drawPolygon(s);

/* `Array^t は実質的に値渡しなので,`drawPolygon()^c に渡された
   `Array^t を改変しても, `Canvas^T には効果を及ぼさないことが保証される。 */
a[4] = 20;
var b = canvas.getLastDrawnPolygon();
alert(b[4]);    // これは `50^l を alert することになる。

4.2.26. ~promise型 — `Promise<~varT>^T

~IDL`~promise型$値は ~JS `Promise^t ~objにより表現される。 ◎ IDL promise type values are represented by ECMAScript Promise objects.

次の~algoにより, ~JS値 %V は~IDL `promise_T^ 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL Promise<T> value as follows:

  1. %resolve := `Promise^.resolve の元の値 ◎ Let resolve be the original value of %Promise%.resolve.

    ~JSは、[ well-known 内在的~obj `Promise_resolve^ ]を,ここから参照し得るように増補することになる筈である。 ◎ ECMAScript should grow a %Promise_resolve% well-known intrinsic object that can be referenced here.

  2. %promise := [ `this^v 値に `Promise^, 単独の引数に %V ]を渡して,%resolve を~callした結果 ◎ Let promise be the result of calling resolve with %Promise% as the this value and V as the single argument value.
  3. ~RET %promise と同じ~objへの参照である~IDL`~promise型$値 ◎ Return the IDL promise type value that is a reference to the same object as promise.

~IDL`~promise型$値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Promise^t 値になる。 ◎ The result of converting an IDL promise type value to an ECMAScript value is the Promise value that represents a reference to the same object that the IDL promise type represents.

~promiseが決着したとき、すなわち,それが[ 充足された, または却下された ]とき、それぞれに応じて,何らかの手続きが遂行され得る — そのいずれかは省略され得る 【 これらの手続きは、~promiseを利用する仕様が指定する 】 。 仕様にて `~promiseが決着したときの手続きを遂行する@ と記された所では、次の手続きに従わ~MUST: ◎ One can perform some steps once a promise is settled. There can be one or two sets of steps to perform, covering when the promise is fulfilled, rejected, or both. When a specification says to perform some steps once a promise is settled, the following steps MUST be followed:

  1. %promise := 型 `promise_T^ の~promise~obj ◎ Let promise be the promise object of type Promise<T>.
  2. %onFulfilled := 被呼出時の挙動が次で与えられる,新たな`関数~obj$ ◎ Let onFulfilled be a new function object whose behavior when invoked is as follows:

    1. ~IF %T は `void$T 型 ⇒ ◎ If T is void, then:

      1. ~RET ~promiseが充足-時に走らせることが要求されている手続きを遂行した結果 ◎ Return the result of performing any steps that were required to be run if the promise was fulfilled.
    2. ~ELSE ⇒ ◎ Otherwise, T is a type other than void:

      1. %V := %onFulfilled に渡された第一~引数 ◎ Let V be the first argument to onFulfilled.
      2. %value := %V を型 %T の~IDL値に`toIDL^した結果 ◎ Let value be the result of converting V to an IDL value of type T.
      3. ~IF [ ~promiseの充足-時に走らせることが要求されている手続き ]がある ~THEN ~RET ~promiseの値として %value を渡して,その手続きを遂行した結果 ◎ If there are no steps that are required to be run if the promise was fulfilled, then return undefined. ◎ Otherwise, return the result of performing any steps that were required to be run if the promise was fulfilled, with value as the promise’s value.
      4. ~RET `undefined^v ◎ ↑
  3. %onRejected := 被呼出時の挙動が次で与えられる,新たな`関数~obj$: ◎ Let onRejected be a new function object whose behavior when invoked is as follows:

    1. %R := %onRejected に渡された第一~引数 ◎ Let R be the first argument to onRejected.
    2. %reason := %R を~IDL `any$T 型~値に`toIDL^した結果 ◎ Let reason be the result of converting R to an IDL value of type any.
    3. ~IF [ ~promiseの却下-時に走らせることが要求されている手続き ]がある ~THEN ~RET 却下~事由として %reason を渡して,その手続きを遂行した結果 ◎ If there are no steps that are required to be run if the promise was rejected, then return undefined. ◎ Otherwise, return the result of performing any steps that were required to be run if the promise was rejected, with reason as the rejection reason.
    4. ~RET `undefined^v ◎ ↑
  4. %then := ~prop名 `then^l により, %promise の `Get^es 内的~methを~callした結果 ◎ Let then be the result of calling the internal [[Get]] method of promise with property name “then”.
  5. ~IF %then は`~callable$でない ~THEN ~THROW `TypeError^t ◎ If then is not callable, then throw a TypeError.
  6. ~RET [ `this^v 値に %promise, その2個の引数に ( %onFulfilled, %onRejected ) ]を渡して,%then を~callした結果 ◎ Return the result of calling then with promise as the this value and onFulfilled and onRejected as its two arguments.

この用語を利用する仕様の記述例を含める必要がある。 ◎ Include an example of how to write spec text using this term.

4.2.27. 共用体~型

~IDL`共用体~型$の値は 共用体の`~mb型$に対応する~JS値により表現される。 ◎ IDL union type values are represented by ECMAScript values that correspond to the union’s member types.

次の~algoにより, ~JS値 %V は ~IDL`共用体~型$の値に`toIDL^される: ◎ To convert an ECMAScript value V to an IDL union type value is done as follows:

  1. ~IF[ %V ~IN { `null^v, `undefined^v } ]~AND[ 当の`共用体~型$は`~nullable型を内包する$ ] ~THEN ~RET ~IDL値 `null^V ◎ If the union type includes a nullable type and V is null or undefined, then return the IDL value null.
  2. %types := 当の`共用体~型$の`平坦化~mb型$ ◎ Let types be the flattened member types of the union type.
  3. ~IF[ %V ~IN { `null^v, `undefined^v } ]~AND[ %types に`辞書~型$が含まれている ] ~THEN ~RET %V をその辞書~型に`toIDL^した結果 ◎ If V is null or undefined, and types includes a dictionary type, then return the result of converting V to that dictionary type.
  4. ~IF %V は `~platform~obj$である ⇒ ◎ If V is a platform object, then:

    1. ~IF %types に %V が実装する `~ifc型$が含まれている ~THEN ~RET ~obj %V への参照である~IDL値 ◎ If types includes an interface type that V implements, then return the IDL value that is a reference to the object V.
    2. ~IF %types に `object$T が含まれている ~THEN ~RET ~obj %V への参照である~IDL値 ◎ If types includes object, then return the IDL value that is a reference to the object V.
  5. ~IF %V は ~native `RegExp^t ~objである ⇒ ◎ If V is a native RegExp object, then:

    1. ~IF %types に `RegExp$T が含まれている ~THEN ~RET %V を `RegExp$T に`toIDL^した結果 ◎ If types includes RegExp, then return the result of converting V to RegExp.
  6. ~IF %V は `DOMException^t ~platform~objである ⇒ ◎ If V is a DOMException platform object, then:

    1. ~IF %types に `DOMException$T または `Error$T が含まれている ~THEN ~RET %V を その型に`toIDL^した結果 ◎ If types includes DOMException or Error, then return the result of converting V to that type.
  7. ~IF %V は ~native `Error^t ~objである(すなわち, `ErrorData^es `internal_slot^を持つ) ⇒ ◎ If V is a native Error object (that is, it has an [[ErrorData]] internal slot), then:

    1. ~IF %types に `Error$T が含まれている ~THEN ~RET %V を `Error$T に`toIDL^した結果 ◎ If types includes Error, then return the result of converting V to Error.
  8. ~IF %V は `ArrayBufferData^es `internal_slot^を伴う~objである ⇒ ◎ If V is an object with an [[ArrayBufferData]] internal slot, then:

    1. ~IF %types に `ArrayBuffer$T が含まれている ~THEN ~RET %V を `ArrayBuffer$T に`toIDL^した結果 ◎ If types includes ArrayBuffer, then return the result of converting V to ArrayBuffer.
  9. ~IF %V は `DataView^es `internal_slot^を伴う~objである ⇒ ◎ If V is an object with a [[DataView]] internal slot, then:

    1. ~IF %types に `DataView$T が含まれている ~THEN ~RET %V を `DataView$T に`toIDL^した結果 ◎ If types includes DataView, then return the result of converting V to DataView.
  10. ~IF %V は `TypedArrayName^es `internal_slot^を伴う~objである ⇒ ◎ If V is an object with a [[TypedArrayName]] internal slot, then:

    1. ~IF %types に[ `有型~配列~型$であって,[ その型~名 ~EQ %V の `TypedArrayName^es `internal_slot^ の値 ]なるもの ]が含まれている ~THEN ~RET %V をその型に`toIDL^した結果 ◎ If types includes a typed array type whose name is the value of V’s [[TypedArrayName]] internal slot, then return the result of converting V to that type.
  11. ~IF `IsCallable$A( %V ) ~EQ ~true ⇒ ◎ If IsCallable(V) is true, then:

    1. ~IF %types に`呼戻~関数$型が含まれている ~THEN ~RET %V をその呼戻~関数~型に`toIDL^した結果 ◎ If types includes a callback function type, then return the result of converting V to that callback function type.
  12. ~IF %V は ~native `RegExp^t ~objを除く任意の種類の~objである ⇒ ◎ If V is any kind of object except for a native RegExp object, then:

    1. ~IF %types に`連列~型$が含まれている ⇒ ◎ If types includes a sequence type, then

      1. ~IF %method ~NEQ `undefined^v ~THEN ~RET %V, %method から その型の`連列~値を作成-$した結果 ◎ If method is not undefined, return the result of creating a sequence of that type from V and method.
    2. ~IF %types に`凍結~配列~型$が含まれている ⇒ ◎ If types includes a frozen array type, then

      1. ~IF %method ~NEQ `undefined^v ~THEN ~RET %V, %method から その型の`凍結~配列~値を作成-$した結果 ◎ If method is not undefined, return the result of creating a frozen array of that type from V and method.
    3. ~IF %types に`辞書~型$が含まれている ~THEN ~RET %V をその型に`toIDL^した結果 ◎ If types includes a dictionary type, then return the result of converting V to that dictionary type.
    4. ~IF %types に`呼戻~ifc$型が含まれている ~THEN ~RET %V をその型に`toIDL^した結果 ◎ If types includes a callback interface type, then return the result of converting V to that interface type.
  13. ~IF %V は `Boolean^t 値である ⇒ ◎ If V is a Boolean value, then:

    1. ~IF %types に `boolean$T が含まれている ~THEN ~RET %V を `boolean$T に`toIDL^した結果 ◎ If types includes a boolean, then return the result of converting V to boolean.
  14. ~IF %V は `Number^t 値である ⇒ ◎ If V is a Number value, then:

    1. ~IF %types に`実数~型$が含まれている ~THEN ~RET %V をその`実数~型$に`toIDL^した結果 ◎ If types includes a numeric type, then return the result of converting V to that numeric type.
  15. ~IF %types に`文字列~型$が含まれている ~THEN ~RET %V をその型に`toIDL^した結果 ◎ If types includes a string type, then return the result of converting V to that type.

~IDL共用体~型の値 %U は,次のように~JS値へ`toES^される: %U が[ ~JS `undefined^v 値を表現する特別な~objへの `object$T 参照 ]ならば、~JS `undefined^v 値に変換される。 他の場合、この 4.2 節にて述べている, %U の`固有型$を変換するための規則に従う。 ◎ An IDL union type value is converted to an ECMAScript value as follows. If the value is an object reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, the rules for converting the specific type of the IDL union type value as described in this section (4.2).

4.2.28. `RegExp^T

~IDL `RegExp$T 値は、~JS `RegExp^t ~objにより表現される。 ◎ IDL RegExp values are represented by ECMAScript RegExp objects.

次の~algoにより, ~JS値 %V は~IDL `RegExp$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL RegExp value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は ~native `RegExp^t でない ] ~THEN %V ← [ `現在の大域環境$に属するの[ 標準の組込みの[ 名前 `RegExp^c の構築子 ]]により、式 new RegExp(%V) から作成されるもの ]と同じ,新たな `RegExp^t ~obj ◎ If Type(V) is not Object, or V is not a native RegExp object, then set V to be a newly created RegExp object created as if by the expression new RegExp(V), where RegExp is the standard built-in constructor with that name from the current global environment.

    %V が文字列に変換された際に,正規表現として妥当でない構文である場合、例外が投出され得ることに注意。 ◎ Note that this can result in an exception being thrown, if V, when converted to a string, does not have valid regular expression syntax.

  2. ~RET %V と同じ~objへの参照である~IDL `RegExp$T 値 ◎ Return the IDL RegExp value that is a reference to the same object as V.

~IDL `RegExp$T 値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `RegExp^t 値である。 ◎ The result of converting an IDL RegExp value to an ECMAScript value is the RegExp value that represents a reference to the same object that the IDL RegExp represents.

4.2.29. `Error^T

~IDL `Error$T 値は、[ ~native~JS `Error^t ~obj / `DOMException$ に対する~platform~obj ]により表現される。 ◎ IDL Error values are represented by native ECMAScript Error objects and platform objects for DOMExceptions.

次の~algoにより, ~JS値 %V は~IDL `Error$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL Error value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は `ErrorData^es `internal_slot^ を持たない ] ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Object, or V does not have an [[ErrorData]] internal slot, then throw a TypeError.
  2. ~RET %V と同じ~objへの参照である~IDL `Error$T 値 ◎ Return the IDL Error value that is a reference to the same object as V.

~IDL `Error$T 値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Error^t 値である。 ◎ The result of converting an IDL Error value to an ECMAScript value is the Error value that represents a reference to the same object that the IDL Error represents.

4.2.30. `DOMException^T

~IDL `DOMException$T 値は、 `DOMException$ に対する~platform~objにより表現される。 ◎ IDL DOMException values are represented by platform objects for DOMExceptions.

次の~algoにより, ~JS値 %V は~IDL `DOMException$ 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL DOMException value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は `DOMException$ を表現する~platform~objでない ] ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Object, or V is not a platform object that represents a DOMException, then throw a TypeError.
  2. ~RET %V と同じ~objへの参照である~IDL `DOMException$T 値 ◎ Return the IDL DOMException value that is a reference to the same object as V.

~IDL `DOMException$T 値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Object^t 値である。 ◎ The result of converting an IDL DOMException value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL DOMException represents.

4.2.31. ~buffer~source型

~IDL`~buffer~source型$の値は、対応する~JS~classの~objにより表現される。 ◎ Values of the IDL buffer source types are represented by objects of the corresponding ECMAScript class.

次の~algoにより, ~JS値 %V は~IDL `ArrayBuffer$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL ArrayBuffer value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は `ArrayBufferData^es `internal_slot^ を持たない ]~OR[ `IsDetachedBuffer$A( %V ) ~EQ `true^v ] ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Object, or V does not have an [[ArrayBufferData]] internal slot, or IsDetachedBuffer(V) is true, then throw a TypeError.
  2. ~RET %V と同じ~objへの参照である~IDL `ArrayBuffer$T 値 ◎ Return the IDL ArrayBuffer value that is a reference to the same object as V.

次の~algoにより, ~JS値 %V は~IDL `DataView$T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL DataView value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は `DataView^es `internal_slot^ を持たない ] ~THEN ~THROW `TypeError^t ◎ If Type(V) is not Object, or V does not have a [[DataView]] internal slot, then throw a TypeError.
  2. ~RET %V と同じ~objへの参照である~IDL `DataView$T 値 ◎ Return the IDL DataView value that is a reference to the same object as V.

%T をいずれかの`有型~配列~型$とするとき、次の~algoにより,~JS値 %V は~IDL %T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL Int8Array, Int16Array, Int32Array, Uint8Array, Uint16Array, Uint32Array, Uint8ClampedArray, Float32Array or Float64Array value by running the following algorithm:

  1. ~IF[ `Type^( %V ) ~NEQ `Object^t ]~OR[ %V は [ 値が %T の型~名に等しい `TypedArrayName^es `internal_slot^ ]を持たない ] ~THEN ~THROW `TypeError^t ◎ Let T be the IDL type V is being converted to. ◎ If Type(V) is not Object, or V does not have a [[TypedArrayName]] internal slot with a value equal to the name of T, then throw a TypeError.
  2. ~RET %V と同じ~objへの参照である~IDL %T 値 ◎ Return the IDL value of type T that is a reference to the same object as V.

いずれの`~buffer~source型$に対しても、その型の~IDL値 %V を~JS値に`toES^した結果は, %V が表現するものと同じ~objへの参照を表現する `Object^t 値である。 ◎ The result of converting an IDL value of any buffer source type to an ECMAScript value is the Object value that represents a reference to the same object that the IDL value represents.

[ ~JS[ `ArrayBuffer^t, `DataView^t, `有型~配列~型$ ]のいずれかの ~objである,~buffer~source %O ]に保持されている~byte列の`参照/複製を取得-$するときは、次の手続きに従わ~MUST: ◎ When getting a reference to or getting a copy of the bytes held by a buffer source that is an ECMAScript ArrayBuffer, DataView or typed array object, these steps MUST be followed:

  1. %arrayBuffer :← %O ◎ Let O be the ECMAScript object that is the buffer source. ◎ Initialize arrayBuffer to O.
  2. %offset :← 0 ◎ Initialize offset to 0.
  3. %length :← 0 ◎ Initialize length to 0.
  4. ~IF %O は `ViewedArrayBuffer^es `internal_slot^ を持つ ⇒ ◎ If O has a [[ViewedArrayBuffer]] internal slot, then:

    1. %arrayBuffer ← %O の `ViewedArrayBuffer^es `internal_slot^ の値 ◎ Set arrayBuffer to the value of O’s [[ViewedArrayBuffer]] internal slot.
    2. ~IF %arrayBuffer ~EQ `undefined^v ~THEN ~THROW `TypeError^t ◎ If arrayBuffer is undefined, then throw a TypeError.
    3. %offset ← %O の `ByteOffset^es `internal_slot^ の値 ◎ Set offset to the value of O’s [[ByteOffset]] internal slot.
    4. %length ← %O の `ByteLength^es `internal_slot^ の値 ◎ Set length to the value of O’s [[ByteLength]] internal slot.
  5. ~ELSE %length ← %O の `ArrayBufferByteLength^es `internal_slot^ の値 ◎ Otherwise, set length to the value of O’s [[ArrayBufferByteLength]] internal slot.
  6. ~IF `IsDetachedBuffer$A( %O ) ~THEN ~THROW `TypeError^t ◎ If IsDetachedBuffer(O), then throw a TypeError.
  7. %data := %O の `ArrayBufferData^es `internal_slot^ の値 ◎ Let data be the value of O’s [[ArrayBufferData]] internal slot.
  8. ~RET [ %data 内の~byte~offset %offset の所から, %length 個の~byte ][ への参照, または の複製 ](いずれか要求された方)。 ◎ Return a reference to or copy of (as required) the length bytes in data starting at byte offset offset.

`ArrayBuffer$T ~objを`切離す$ときは、次の手続きに従わ~MUST: ◎ To detach an ArrayBuffer, these steps MUST be followed:

  1. %O := その[ `ArrayBuffer$T である~JS~obj ] ◎ Let O be the ECMAScript object that is the ArrayBuffer.
  2. `DetachArrayBuffer$A( %O ) ◎ DetachArrayBuffer(O).

4.2.32. 凍結~配列 — `FrozenArray<~varT>^T

`凍結~配列~型$の値は、~~凍結された( frozen )~JS `Array^t ~obj参照により表現される。 ◎ Values of frozen array types are represented by frozen ECMAScript Array object references.

次の~algoにより, ~JS値 %V は~IDL `FrozenArray<~varT>^T 値に`toIDL^される: ◎ An ECMAScript value V is converted to an IDL FrozenArray<T> value by running the following algorithm:

  1. %values := %V を~IDL `sequence<~varT>^T 型に`toIDL^した結果 ◎ Let values be the result of converting V to IDL type sequence<T>.
  2. ~RET %values から`凍結~配列を作成-$した結果 ◎ Return the result of creating a frozen array from values.

型 ~varT の値の連列から `凍結~配列を作成-@ するときは、次の手続きに従う: ◎ To create a frozen array from a sequence of values of type T, follow these steps:

  1. %array := 値の連列を~JS値に`toES^した結果 ◎ Let array be the result of converting the sequence of values to an ECMAScript value.
  2. `SetIntegrityLevel$A(%array, "frozen") を遂行する ◎ Perform SetIntegrityLevel(array, "frozen").
  3. ~RET %array ◎ Return array.

~IDL `FrozenArray<~varT>^T 値 %V を~JS値に`toES^した結果は、 %V が表現するものと同じ~objへの参照を表現する `Object^t 値である。 ◎ The result of converting an IDL FrozenArray<T> value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL FrozenArray<T> represents.

4.2.32.1. 可反復から凍結~配列を作成する

所与の[ 可反復 %iterable, 反復子~取得子 %method ]から 型 `FrozenArray_T^ の~IDL値を作成するときは,次の手続きを遂行する: ◎ To create an IDL value of type FrozenArray<T> given an iterable iterable and an iterator getter method, perform the following steps:

  1. %values := %iterable, %method から型 ~varT の`連列~値を作成-$した結果 ◎ Let values be the result of creating a sequence of type sequence<T> from iterable and method.
  2. ~RET %values から`凍結~配列を作成-$した結果 ◎ Return the result of creating a frozen array from values.

4.3. ~JS固有の拡張属性

この節では、その存在tが~JS言語束縛にのみ影響する いくつかの`拡張属性$を定義する。 ◎ This section defines a number of extended attributes whose presence affects only the ECMAScript binding.

4.3.1. `Clamp^x

`Clamp$x `拡張属性$が[ `整数~型$の[ `演算$の引数 / ~writableな`属性$ / `辞書~mb$ ]]上に現れた場合、 ~JS `Number^t から~IDL型への変換-において,範囲~外の値は、 modulo 演算( `ToInt32$A, `ToUint32$A, 等々)を利用する演算子を利用せずに,範囲~内の妥当な値に切詰められる(切り上げ/切り下げされる)ことになる。 ◎ If the [Clamp] extended attribute appears on an operation argument, writable attribute or dictionary member whose type is one of the integer types, it indicates that when an ECMAScript Number is converted to the IDL type, out of range values will be clamped to the range of valid values, rather than using the operators that use a modulo operation (ToInt32, ToUint32, etc.).

`Clamp$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `読専$の属性に現れては~MUST_NOT。
  • `整数~型$でない[ 属性/演算~引数/辞書~mb ]に現れては~MUST_NOT。
  • `EnforceRange$x 拡張属性と併用されては~MUST_NOT。
◎ The [Clamp] extended attribute MUST take no arguments. ◎ The [Clamp] extended attribute MUST NOT appear on a read only attribute, or an attribute, operation argument or dictionary member that is not of an integer type. It also MUST NOT be used in conjunction with the [EnforceRange] extended attribute.

`Clamp$x の利用に課される固有の要件については、 ~JS値から種々の~IDL整数~型への変換-規則について述べた `es-type-mapping$sec に。 ◎ See the rules for converting ECMAScript values to the various IDL integer types in section 4.2 for the specific requirements that the use of [Clamp] entails.

次の`~IDL片$では,それぞれが3個の `octet$T 引数をとる,2個の`演算$が宣言される。 一方には3個すべての引数に `Clamp$x `拡張属性$が利用され,他方はそうでない: ◎ In the following IDL fragment, two operations are declared that take three octet arguments; one uses the [Clamp] extended attribute on all three arguments, while the other does not:

interface GraphicsContext {
  void setColor(octet red, octet green, octet blue);
  void setColorClamped([Clamp] octet red, [Clamp] octet green, [Clamp] octet blue);
};

この~IDLの~JS実装においては、 `setColorClamped^M の~callに渡された, `octet$T の範囲~外の `Number^t 値は、範囲 [0, 255] に切詰められる。 ◎ In an ECMAScript implementation of the IDL, a call to setColorClamped with Number values that are out of range for an octet are clamped to the range [0, 255].

// `GraphicsContext^T の~instanceを取得する。
var context = getGraphicsContext();

// 非 `Clamp^x 版の~callは実数~値を~octetに強制する ToUint8 を利用する。
// 次は `setColor(255, 255, 1)^c の~callと等価。
context.setColor(-1, 255, 257);

// 範囲~外の値を渡して `setColorClamped^M を~call。
// 次は `setColorClamped(0, 255, 255)^c の~callと等価。
context.setColorClamped(-1, 255, 257);

4.3.2. `Constructor^x

`Constructor$x `拡張属性$が `~ifc$上に現れた場合、その~ifcに対応する`~ifc~obj$は,[ その~ifcを実装する~objを構築し得るようにする, `Construct^es 内的~meth ]を持つことになる。 ◎ If the [Constructor] extended attribute appears on an interface, it indicates that the interface object for this interface will have an [[Construct]] internal method, allowing objects implementing the interface to be constructed.

同じ~ifc上に複数の `Constructor$x 拡張属性が現れてもよい。 ◎ Multiple [Constructor] extended attributes may appear on a given interface.

`Constructor$x 拡張属性には、[ `引数をとらない$ か, または `有名~引数~listを引数にとる$ ]ことが~REQUIRED。 略記形の前者 `[Constructor]^c は、引数~listが空にされた `[Constructor()]^c と同じ意味になる。 ~ifc上のそれぞれの `Constructor$x 拡張属性が、[ 指定された引数を渡して,その~ifcを実装する~objを構築する仕方 ]を、供することになる。 ◎ The [Constructor] extended attribute MUST either take no arguments or take an argument list. The bare form, [Constructor], has the same meaning as using an empty argument list, [Constructor()]. For each [Constructor] extended attribute on the interface, there will be a way to construct an object that implements the interface by passing the specified arguments.

構築子の注釈文においては,[ `Constructor$x 拡張属性が現れる~ifcに対応する型の~IDL値を返すか, または 例外を投出する ]ように定義され~MUST。 ◎ The prose definition of a constructor MUST either return an IDL value of a type corresponding to the interface the [Constructor] extended attribute appears on, or throw an exception.

`Constructor$x 拡張属性は:

  • 同じ~ifc上で, `NoInterfaceObject$x 拡張属性と併用されては~MUST_NOT。 ◎ The [Constructor] and [NoInterfaceObject] extended attributes must not be specified on the same interface.
  • `呼戻~ifc$上に利用されては~MUST_NOT。 ◎ The [Constructor] extended attribute MUST NOT be used on a callback interface.

~ifcに対する構築子がどう実装されるかの詳細は `es-interface-call$sec に。 ◎ See section 4.6.1.1 below for details on how a constructor for an interface is to be implemented.

次の~IDLは2つの~ifcを定義する。 二番目のものは `Constructor$x 拡張属性を持つ一方,最初のものは持たない。 ◎ The following IDL defines two interfaces. The second has the [Constructor] extended attribute, while the first does not.

interface NodeList {
  Node item(unsigned long index);
  readonly attribute unsigned long length;
};

[Constructor,
 Constructor(double radius)]
interface Circle {
  attribute double r;
  attribute double cx;
  attribute double cy;
  readonly attribute double circumference;
};

これらの~ifcを~supportする~JS実装は、 `Circle^T ~ifc~obj上に,[ その~ifcを実装する新たな~obj ]を返す `Construct^es ~propを持つことになる。 それは 0 個または 1 個の引数をとる。 `NodeList^T ~ifc~objは `Construct^es ~propを持たないことになる。 ◎ An ECMAScript implementation supporting these interfaces would have a [[Construct]] property on the Circle interface object which would return a new object that implements the interface. It would take either zero or one argument. The NodeList interface object would not have a [[Construct]] property.

var x = new Circle();      
       // これは,引数なしの構築子を利用して、 `Circle^T ~ifcを
//        実装する~platform~objへの参照を作成する。

var y = new Circle(1.25);  
       // 今度は1引数の構築子を利用して `Circle^T ~objを作成する。

var z = new NodeList();    
       // `Constructor^x が宣言されていないので
//        `TypeError^t が投出されることになる。

4.3.3. `EnforceRange^x

`EnforceRange$x `拡張属性$が[ `演算$の引数 / ~writableな`正則~属性$/ `整数~型$の`辞書~mb$ ]に現れた場合、 ~JS `Number^t がその~IDL型に変換される際に,範囲~外の値に対しては、 modulo 演算を利用する演算子( `ToInt32$A, `ToUint32$A, 等々)を利用して妥当な値に変換される代わりに,例外が投出されるようになる。 `Number^t は、その範囲が検査される前に,ゼロ側に丸められる。 ◎ If the [EnforceRange] extended attribute appears on an operation argument, writable regular attribute or dictionary member whose type is one of the integer types, it indicates that when an ECMAScript Number is converted to the IDL type, out of range values will cause an exception to be thrown, rather than converted to being a valid value using the operators that use a modulo operation (ToInt32, ToUint32, etc.). The Number will be rounded towards zero before being checked against its range.

`EnforceRange$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • [ `読専$属性 / `静的~属性$ ]に現れては~MUST_NOT。
  • `整数~型$でない[ 属性 / 演算~引数 / 辞書~mb ]に現れては~MUST_NOT。
  • `Clamp$x 拡張属性と併用されては~MUST_NOT。
◎ The [EnforceRange] extended attribute MUST take no arguments. ◎ The [EnforceRange] extended attribute MUST NOT appear on a read only attribute, a static attribute, or an attribute, operation argument or dictionary member that is not of an integer type. It also MUST NOT be used in conjunction with the [Clamp] extended attribute.

`EnforceRange$x の利用に課される固有の要件については、[ ~JS値から種々の~IDL整数~型への変換-規則 ]について述べている `es-type-mapping$sec にて。 ◎ See the rules for converting ECMAScript values to the various IDL integer types in section 4.2 for the specific requirements that the use of [EnforceRange] entails.

次の`~IDL片$では,それぞれが3個の `octet$T 引数をとる,2個の`演算$が宣言される。 一方には3個すべての引数に `EnforceRange$x `拡張属性$が利用され,他方はそうでない: ◎ In the following IDL fragment, two operations are declared that take three octet arguments; one uses the [EnforceRange] extended attribute on all three arguments, while the other does not:

interface GraphicsContext {
  void setColor(octet red, octet green, octet blue);
  void setColorEnforcedRange([EnforceRange] octet red, [EnforceRange] octet green, [EnforceRange] octet blue);
};

この~IDLの~JS実装においては、 `octet$T の範囲~外の `Number^t 値を渡して `setColorEnforcedRange^M を~callしたときの結果は、例外の投出になる。 ◎ In an ECMAScript implementation of the IDL, a call to setColorEnforcedRange with Number values that are out of range for an octet will result in an exception being thrown.

// `GraphicsContext^T の~instanceを取得する。
var context = getGraphicsContext();

/* 非 `EnforceRange^x 版の~callは実数~値を~octetに強制する ToUint8 を
  利用する。これは `setColor(255, 255, 1)^c の~callと等価になる。 */
context.setColor(-1, 255, 257);

/* 実数~値は `setColorEnforcedRange^M が~callされる際にゼロ側に丸められる。
   これは `setColor(0, 255, 255)^c の~callと等価になる。 */
context.setColorEnforcedRange(-0.9, 255, 255.2);

/* 次は `TypeError^t を投出させる。丸められた後でも,
   第一, 第三~引数は範囲~外になるので。 */
context.setColorEnforcedRange(-1, 255, 256);

4.3.4. `Exposed^x

`Exposed$x `拡張属性$が[[ `~ifc$ / `部分的~ifc定義$ ]/ 個々の`~ifc~mb$ ]上に現れた場合、その[ ~ifc / ~ifc~mb ]が,特定0の[ 大域~ifcの集合 ]上に公開されることを指示する — 既定による,`主~大域~ifc$上でのみ公開されるのではなく。 ◎ If the [Exposed] extended attribute appears on an interface, partial interface, or an individual interface member, it indicates that the interface or interface member is exposed on a particular set of global interfaces, rather than the default of being exposed only on the primary global interface.

`Exposed$x `拡張属性$には、 `識別子を引数にとる$か, または `識別子~listを引数にとる$ことが~REQUIRED。 引数に挙げられた各~識別子は`大域~名$で~MUST。 ◎ The [Exposed] extended attribute MUST either take an identifier or take an identifier list. Each of the identifiers mentioned MUST be a global name.

`Exposed$x `拡張属性$を指定し得る どの構成子も, `公開~集合@ を持つ — それは、`~ifc$の集合であり,その構成子が どの大域環境で利用し得るかを定義する。 所与の構成子に対する`公開~集合$は、次で定義される: ◎ Every construct that the [Exposed] extended attribute can be specified on has an exposure set, which is a set of interfaces defining which global environments the construct can be used in. The exposure set for a given construct is defined as follows:

  • [ `Exposed$x `拡張属性$が指定されている構成子 ]の`公開~集合$は,[ その拡張属性の引数に挙げられている いずれかの`大域~名$ ]を持つ~ifcからなる。 ◎ If the [Exposed] extended attribute is specified on the construct, then the exposure set is the set of all interfaces that have a global name that is listed in the extended attribute's argument.
  • 下に挙げる構成子のうち, `Exposed$x 拡張属性が現れないものに対しては、その構成子の型に依存して,その`公開~集合$が暗黙的に定義される: ◎ If the [Exposed] extended attribute does not appear on a construct, then its exposure set is defined implicitly, depending on the type of construct:

    ~ifc◎interface
    `主~大域~ifc$のみからなる。 ◎ The exposure set of the interface only contains the primary global interface.
    部分的~ifc◎partial interface
    元の~ifc定義の`公開~集合$と同じ。 ◎ The exposure set of the partial interface is the exposure set of the original interface definition.
    ~ifc~mb◎interface member
    その~mbが宣言されている[ ~ifc/部分的~ifc ]の`公開~集合$と同じ。 ◎ The exposure set of the interface member is the exposure set of the interface or partial interface the member is declared on.

`Exposed$x 拡張属性は:

  • [ `多重定義$されている`演算$ ]上に現れるときは、その演算のすべての多重定義~上に,引数も含めて全く同じに現れ~MUST。 ◎ If [Exposed] appears on an overloaded operation, then it MUST appear identically on all overloads.
  • [ ~ifc~mbと, その~ifc~mbを宣言している部分的~ifc定義 ]の両者に指定されては~MUST_NOT。 ◎ The [Exposed] extended attribute MUST NOT be specified on both an interface member and a partial interface definition the interface member is declared on.
  • ~ifc %I とその~ifc~mb %m の両者に現れた場合、 %m の`公開~集合$は, %I の`公開~集合$の部分集合で~MUST。 ◎ If [Exposed] appears on both an interface and one of its interface members, then the interface member's exposure set MUST be a subset of the interface's exposure set.
  • `Constructor$x 拡張属性を持たない`辞書$上に指定されては~MUST_NOT。 ◎ ↓

~ifcの`公開~集合$は: ◎ ↓

  • その`帰結~ifc$すべての`公開~集合$の和集合の部分集合で~MUST。 ◎ An interface's exposure set MUST be a subset of the exposure set of all of the interface's consequential interfaces.
  • 別の~ifcを`継承-$しているならば、その~ifcの`公開~集合$の部分集合で~MUST。 ◎ If an interface X inherits from another interface Y then the exposure set of X MUST be a subset of the exposure set of Y.

[ `~ifc$/`~ifc~mb$/`辞書$ ] %X が,所与の~JS大域環境 %G において `公開され@ るとは、 %G が[ %X の`公開~集合$に属する ある~ifc ]を実装していて,次のいずれかを満たすことを意味する: ◎ An interface or interface member is exposed in a given ECMAScript global environment if the ECMAScript global object implements an interface that is in the interface or interface member's exposure set, and either:

  • ~JS大域~objに`関連する設定群~obj$は `保安的~文脈$であるか, または ◎ the relevant settings object for the ECMAScript global object is a secure context; or
  • %X は`保安的~文脈~下に限り可用$ではない。 ◎ the interface or interface member is not available only in secure contexts.

~JS大域~objに`関連する設定群~obj$が`保安的~文脈$であるかどうかは,変化し得ないので、 %X に対する~propを作成するかどうかの実装による決断は、`初期~obj$を作成する時点の一度限りになる。 ◎ Since it is not possible for the relevant settings object for an ECMAScript global object to change whether it is a secure context or not over time, an implementation's decision to create properties for an interface or interface member can be made once, at the time the initial objects are created.

`Exposed$x の利用に課される固有の要件については `es-interfaces$sec, `es-constants$sec, `es-attributes$sec, `es-operations$sec, `es-iterators$sec に。 ◎ See section 4.6, section 4.6.5, section 4.6.6, section 4.6.7 and section 4.6.8 for the specific requirements that the use of [Exposed] entails.

`Exposed$x には、~ifcや個々の~ifc~mbを[ `Worker^T Web Workers や `Window^T, あるいはその両者 ]の中でのみ可用にするかどうかを制御する用途が意図されている。 ◎ [Exposed] is intended to be used to control whether interfaces or individual interface members are available for use only in workers, only in the Window, or in both.

それがどのように得られるかを,次の~IDL片に示す: ◎ The following IDL fragment shows how that might be achieved:

[PrimaryGlobal]
interface Window {
  ...
};

/* `SharedWorkerGlobalScope^T と `DedicatedWorkerGlobalScope^T
   の両者に同じ識別子 `Worker^l を利用する — 両者は
   `Exposed^x 拡張属性からまとめて指せるようになる。 */
[Global=Worker]
interface SharedWorkerGlobalScope : WorkerGlobalScope {
  ...
};

[Global=Worker]
interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
  ...
};

/* `MathUtils^T は、[ 主thread上と~workerの中 ]でのみ可用。 */
[Exposed=(Window,Worker)]
interface MathUtils {
  static double someComplicatedFunction(double x, double y);
};

/* `WorkerUtils^T は,~workerの中でのみ可用。 `WorkerUtils^T を~workerの
   大域~scopeの中で評価したときは その~ifc~objを得られるが、
   主thread上でそれを行ったときは `ReferenceError^t になる。 */
[Exposed=Worker]
interface WorkerUtils {
  static void setPriority(double x);
};

/* `Node^T は主thread上でのみ可用。~workerの大域~scopeの中で
   `Node^T を評価したときは `ReferenceError^t になる。 */
interface Node {
  ...
};

4.3.5. `ImplicitThis^x

`ImplicitThis$x `拡張属性$が `~ifc$上に現れた場合、 その~ifcの`演算$に対応する `Function^t が, `this^v 値として[ `null^v または `undefined^v ]値を伴って呼出された際に,代わりに~JS大域~objがその `this^v 値に利用されることになる。 これは,~callする~codeが~strict-mode下にあるかどうかには依らない。 ◎ If the [ImplicitThis] extended attribute appears on an interface, it indicates that when a Function corresponding to one of the interface’s operations is invoked with the null or undefined value as the this value, that the ECMAScript global object will be used as the this value instead. This is regardless of whether the calling code is in strict mode.

`ImplicitThis$x 拡張属性には、`引数をとらない$ことが~REQUIRED。 ◎ The [ImplicitThis] extended attribute MUST take no arguments.

`ImplicitThis$x の利用に課される固有の要件については `es-operations$sec に。 ◎ See section 4.6.7 for the specific requirements that the use of [ImplicitThis] entails.

`ImplicitThis$x `拡張属性$は HTML5 ( `HTML5$r, 5.2 節)にて定義されるように, `Window^T `~ifc$上での利用が意図されている。 ◎ The [ImplicitThis] extended attribute is intended for use on the Window interface as defined in HTML5 ([HTML5], section 5.2).

次の例では、 `Window^T `~ifc$が `ImplicitThis$x `拡張属性$を伴って定義される。 ◎ In the following example, the Window interface is defined with the [ImplicitThis] extended attribute.

[ImplicitThis]
interface Window {
  ...
  attribute DOMString name;
  void alert(DOMString message);
};

`Window^T ~objは~JS大域~objとして利用されるので、明示的な~objがなくても, ~strict-mode下にあっても,その関数を~callできる: ◎ Since the Window object is used as the ECMAScript global object, calls to its functions can be made without an explicit object, even in strict mode:

"use strict";

window.alert("hello");      // `Window^T ~objを明示的に与えて alert を~call。
alert("hello");             // これも機能する。~strict-mode下にあっても。
alert.call(null, "hello");  // `this^v 値に明示的に `null^v を渡しても同様。

// しかしながら,~ifc上の属性に対する取得子には適用されない:
// 次は `TypeError^t を投出する。
Object.getOwnPropertyDescriptor(Window.prototype, "name").get.call(null);

4.3.6. `Global^x と `PrimaryGlobal^x

[ `Global$x / `PrimaryGlobal^x ]`拡張属性$が `~ifc$上に現れた場合、その~ifcを実装している~objは ~JS環境にて大域~objとして利用できることを指示する。 また、原型鎖の構造, および[ `~ifc~mb$に対応する~propが原型~obj上にどのように反映されるか ]についても、他の~ifcと異なるものにされることを指示する。 より明確には: ◎ If the [Global] or [PrimaryGlobal] extended attribute appears on an interface, it indicates that objects implementing this interface can be used as the global object in an ECMAScript environment, and that the structure of the prototype chain and how properties corresponding to interface members will be reflected on the prototype objects will be different from other interfaces. Specifically:

  1. どの`有名~prop$も,~obj自身ではなく, 原型鎖の中の~obj — `有名~prop~obj$ — 上にて公開されることになる。 ◎ Any named properties will be exposed on an object in the prototype chain – the named properties object – rather than on the object itself.
  2. `~ifc$のどの`広義~帰結~ifc$のどの`~ifc~mb$も、`~ifc原型~obj$上ではなく, ~obj自身の~propに対応することになる。 ◎ Interface members from the interface (or consequential interfaces) will correspond to properties on the object itself rather than on interface prototype objects.

原型鎖の中の~obj上に置かれる有名~propは、変数~宣言とそのままの名前の代入を通して,大域~obj自身の~propにより隠蔽される。 ◎ Placing named properties on an object in the prototype chain is done so that variable declarations and bareword assignments will shadow the named property with a property on the global object itself.

~ifc~mbに対応する~propを~obj自身の上に置くことは、次の様な,特色機能を検出するためによく利用される手法が機能することになることを意味する: ◎ Placing properties corresponding to interface members on the object itself will mean that common feature detection methods like the following will work:

var indexedDB = window.indexedDB || window.webkitIndexedDB ||
                window.mozIndexedDB || window.msIndexedDB;

var requestAnimationFrame = window.requestAnimationFrame ||
                            window.mozRequestAnimationFrame || ...;

~JSにおける変数~宣言が取扱われる仕方から,代入が評価される前に隠蔽する変数~propが作成されることになるので、上の~codeでは, `window.indexedDB^c と `window.requestAnimationFrame^c が `undefined^c に評価されることになる。 ◎ Because of the way variable declarations are handled in ECMAScript, the code above would result in the window.indexedDB and window.requestAnimationFrame evaluating to undefined, as the shadowing variable property would already have been created before the assignment is evaluated.

`Global$x / `PrimaryGlobal$x `拡張属性$が利用された`~ifc$に対しては: ◎ If the [Global] or [PrimaryGlobal] extended attributes is used on an interface, then:

  • `有名~prop設定子$が定義されては~MUST_NOT。 ◎ The interface MUST NOT define a named property setter.
  • 自身およびその`被継承~ifc$は, `OverrideBuiltins$x 拡張属性が伴われて宣言されては~MUST_NOT。 ◎ The interface MUST NOT also be declared with the [OverrideBuiltins] extended attribute. ◎ The interface MUST NOT inherit from another interface with the [OverrideBuiltins] extended attribute.
  • 他の~ifcが`継承-$しては~MUST_NOT。 ◎ Any other interface MUST NOT inherit from it.

`Global$x / `PrimaryGlobal$x が`部分的~ifc定義$上に指定される場合、その部分的~ifc定義は,~ifc定義の中で`有名~prop取得子$を定義する部分をなすもので~MUST。 ◎ If [Global] or [PrimaryGlobal] is specified on a partial interface definition, then that partial interface definition MUST be the part of the interface definition that defines the named property getter.

`Global$x / `PrimaryGlobal$x `拡張属性$は、同じ~JS大域環境において,複数の~objから実装され得るような`~ifc$上に利用されては~MUST_NOT。 ◎ The [Global] and [PrimaryGlobal] extended attribute MUST NOT be used on an interface that can have more than one object implementing it in the same ECMAScript global environment.

これは、有名~propを公開する`有名~prop~obj$が 原型鎖の中にあるものであり、複数の[~objの有名~prop]を,それらの~objを継承する1個の~obj上で公開することに意味が無いからである。 ◎ This is because the named properties object, which exposes the named properties, is in the prototype chain, and it would not make sense for more than one object’s named properties to be exposed on an object that all of those objects inherit from.

`Global$x / `PrimaryGlobal$x `拡張属性$を伴って宣言された~ifcにおいては、そのどの2つの`広義~帰結~ifc$の間でも,`識別子$が同じになる`~ifc~mb$が存在しては~MUST_NOT。 また、それらの~ifcに渡って,[ 複数の`文字列化子$ / 複数の`直列化子$ / 複数の[ `可反復~宣言$, `~maplike 宣言$, `~setlike 宣言$ 【混在も含む】 ]]が存在しては~MUST_NOT。 ◎ If an interface is declared with the [Global] or [PrimaryGlobal] extended attribute, then there MUST NOT be more than one interface member across the interface and its consequential interfaces with the same identifier. There also MUST NOT be more than one stringifier, more than one serializer, or more than one iterable declaration, maplike declaration or setlike declaration across those interfaces.

その理由は、~ifcとその帰結~ifcの~mbすべてが、~ifcを実装する~objに平坦化されるからである。 ◎ This is because all of the members of the interface and its consequential interfaces get flattened down on to the object that implements the interface.

`Global$x / `PrimaryGlobal$x 拡張属性は, 1 個~以上の大域~ifcに同じ名前を付けて、その名前を通して `Exposed$x 拡張属性から参照する目的にも利用できる。 ◎ The [Global] and [PrimaryGlobal] extended attributes can also be used to give a name to one or more global interfaces, which can then be referenced by the [Exposed] extended attribute.

`Global$x / `PrimaryGlobal$x 拡張属性には、[ `引数をとらない$ か, または `識別子~listを引数にとる$ ]ことが~REQUIRED。 ◎ The [Global] and [PrimaryGlobal] extended attributes MUST either take no arguments or take an identifier list.

`Global$x / `PrimaryGlobal$x `拡張属性$が宣言されている~ifcは, 1 個~以上の `大域~名@ を持つ: 拡張属性が 識別子~listを引数に伴うならば,それらの識別子が~ifcの大域~名になり、他の場合,~ifc自身の識別子が~ifcの~~唯一の大域~名になる。 ◎ If the [Global] or [PrimaryGlobal] extended attribute is declared with an identifier list argument, then those identifiers are the interface’s global names; otherwise, the interface has a single global name, which is the interface's identifier.

識別子~list引数は、 `Exposed$x `拡張属性$の中の単独の名前で,複数の大域~ifcを指せるようにするためにある。 ◎ The identifier argument list exists so that more than one global interface can be addressed with a single name in an [Exposed] extended attribute.

`Global$x, `PrimaryGlobal$x の両`拡張属性$が,同じ~ifc上に宣言されては~MUST_NOT。 `PrimaryGlobal$x 拡張属性が宣言される~ifcは,高々 1 個で~MUST。 `PrimaryGlobal$x が宣言された~ifcは、 `主~大域~ifc@ と呼ばれる。 ◎ The [Global] and [PrimaryGlobal] extended attributes MUST NOT be declared on the same interface. The [PrimaryGlobal] extended attribute MUST be declared on at most one interface. The interface [PrimaryGlobal] is declared on, if any, is known as the primary global interface.

有名~propにおける `Global$x / `PrimaryGlobal$x の利用に課される固有の要件については `named-properties-object$sec, `getownproperty$sec, `defineownproperty$sec に。 `~ifc~mb$に対応する~propの所在に関する要件については `es-constants$sec, `es-attributes$sec, `es-operations$sec に。 ◎ See section 4.6.4, section 4.8.3 and section 4.8.7 for the specific requirements that the use of [Global] and [PrimaryGlobal] entails for named properties, and section 4.6.5, section 4.6.6 and section 4.6.7 for the requirements relating to the location of properties corresponding to interface members.

`PrimaryGlobal$x は、 HTML5 ( `HTML5$r, 5.2 節) で定義されるように, `Window^T ~ifcからの利用が意図されている。 ( `Global$x は,~worker大域~ifcからの利用が意図されている。) `Window^T ~ifcは frame を `Window^T ~obj上の~propとして公開する。 `Window^T ~objは~JS大域~objとしても機能するので、有名~propに対する代入や変数~宣言は、新たな値への置換-になる。 属性に対する変数~宣言は、既存のものを置換する~propを作成しない。 ◎ The [PrimaryGlobal] extended attribute is intended to be used by the Window interface as defined in HTML5 ([HTML5], section 5.2). ([Global] is intended to be used by worker global interfaces.) The Window interface exposes frames as properties on the Window object. Since the Window object also serves as the ECMAScript global object, variable declarations or assignments to the named properties will result in them being replaced by the new value. Variable declarations for attributes will not create a property that replaces the existing one.

[PrimaryGlobal]
interface Window {
  getter any (DOMString name);
  attribute DOMString name; 
   ...
};

次の HTML 文書では、 `Window^T ~obj上の有名~propが隠蔽され, 属性に対する~propは同じ名前の変数が宣言されても置換されない: ◎ The following HTML document illustrates how the named properties on the Window object can be shadowed, and how the property for an attribute will not be replaced when declaring a variable of the same name:

<!DOCTYPE html>
<title>Window 上の変数~宣言と代入</title>
<iframe name=abc></iframe>
<!-- 有名~propを隠蔽する -->
<script>
  window.abc;    // `iframe^c の `Window^T ~objに評価される。
  abc = 1;       // 有名~propを隠蔽する。
  window.abc;    // 
</script>

<!-- ~IDL属性に対する~propは保全される -->
<script>
  Window.prototype.def = 2;         // 原型~上に~propを置く。
  window.hasOwnProperty("length");  // 

  length;        // 
  def;           // `2^v に評価される。
</script>

<script>
  var length;    // この変数~宣言は既存の~propに触らない。
  length;        // 
  var def;       // この変数~宣言は隠蔽する~propを作成する。
  def;           // 
</script>

4.3.7. `LegacyArrayClass^x

`LegacyArrayClass$x `拡張属性$が[ 他を`継承-$しないように定義された`~ifc$ ]上に現れた場合、その`~ifc原型~obj$の `Prototype^es 内的~propは, `Object^t 原型~objではなく, `Array^t 原型~objになる。 これにより、その~ifcを実装している~objにおいて, `Array^t ~methを容易く利用できるようになる。 ◎ If the [LegacyArrayClass] extended attribute appears on an interface that is not defined to inherit from another, it indicates that the internal [[Prototype]] property of its interface prototype object will be the Array prototype object rather than the Object prototype object. This allows Array methods to be used more easily with objects implementing the interface.

`LegacyArrayClass$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `被継承~ifc$を持つ~ifcに利用されては~MUST_NOT:
◎ The [LegacyArrayClass] extended attribute MUST take no arguments. It MUST NOT be used on an interface that has any inherited interfaces.

`LegacyArrayClass$x を利用する~ifcには、継承される `Array^t ~methが正しく演算するように、配列に類似するような,~objの長さを公開する[ 型 `unsigned long^t の `length^l `属性$ ]を定義する必要がある。 そのような~ifcは、概して,配列~要素への~accessを提供する`有index~propを~supportする$ことになるであろう。 ◎ Interfaces using [LegacyArrayClass] will need to define a “length” attribute of type unsigned long that exposes the length of the array-like object, in order for the inherited Array methods to operate correctly. Such interfaces would typically also support indexed properties, which would provide access to the array elements.

`LegacyArrayClass$x の利用に課される固有の要件については `interface-prototype-object$sec に。 ◎ See section 4.6.3 for the specific requirements that the use of [LegacyArrayClass] entails.

次の`~IDL片$は、 `LegacyArrayClass$x を利用する2つの`~ifc$を定義する。 ◎ The following IDL fragment defines two interfaces that use [LegacyArrayClass].

[LegacyArrayClass]
interface ItemList {
  attribute unsigned long length;
  getter object getItem(unsigned long index);
  setter object setItem(unsigned long index, object item);
};

[LegacyArrayClass]
interface ImmutableItemList {
  readonly attribute unsigned long length;
  getter object getItem(unsigned long index);
};

上の2つの~ifcの `getItem^c, `setItem^c, `removeItem^c の適切な定義を伴う ~JS実装においては、配列に類似する~objを検分したり改変するための `Array^t ~methを利用できる: ◎ In an ECMAScript implementation of the above two interfaces, with appropriate definitions for getItem, setItem and removeItem, Array methods to inspect and modify the array-like object can be used.

var list = getItemList();  // `ItemList^T の~instanceを得る。

list.concat();             // %list を `Array^t の中に~cloneする。
list.pop();                // %list から項目を除去する。
list.unshift({ });         // 項目を~index 0 の位置に挿入する。

`ImmutableItemList^T は、読専の `length^c `属性$を持ち, `有index~prop設定子$を持たない。 `ImmutableItemList^T を実装する~obj上では、一般に `Array^t を改変する~methは失敗することになる。 正確な挙動は `Array^t ~meth自身 の定義に依存する ( `ECMA-262$r 22.1.3 節) 。 ◎ ImmutableItemList has a read only length attribute and no indexed property setter. The mutating Array methods will generally not succeed on objects implementing ImmutableItemList. The exact behavior depends on the definition of the Array methods themselves ([ECMA-262], section 22.1.3).

4.3.8. `LegacyUnenumerableNamedProperties^x

`LegacyUnenumerableNamedProperties$x `拡張属性$が[ `有名~propを~supportする$`~ifc$ ]に現れた場合、その~ifc上の すべての有名~propは,列挙不可であることを指示する。 ◎ If the [LegacyUnenumerableNamedProperties] extended attribute appears on a interface that supports named properties, it indicates that all the interface's named properties are unenumerable.

`LegacyUnenumerableNamedProperties$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `有名~prop取得子$を定義しない~ifc上に現れては~MUST_NOT。
  • 当の~ifcのすべての派生~ifcにも適用され、それらには,この拡張属性は指定されては~MUST_NOT。
◎ The [LegacyUnenumerableNamedProperties] extended attribute MUST take no arguments and MUST NOT appear on an interface that does not define a named property getter. ◎ If the [LegacyUnenumerableNamedProperties] extended attribute is specified on an interface, then it applies to all its derived interfaces and MUST NOT be specified on any of them.

`LegacyUnenumerableNamedProperties$x の利用に課される固有の要件については、`property-enumeration$secに。 ◎ See section 4.8.10 for the specific requirements that the use of [LegacyUnenumerableNamedProperties] entails.

4.3.9. `LenientSetter^x

`LenientSetter$x `拡張属性$が[ `読専$の`正則~属性$ ]に現れた場合、[ 属性の~accessor~propとして,何もしない設定子が生成される ]ことを指示する。 その結果,~strict-mode下では、~propに対する誤った代入に対しては,例外は投出されずに無視されるようになる。 ◎ If the [LenientSetter] extended attribute appears on a read only regular attribute, it indicates that a no-op setter will be generated for the attribute’s accessor property. This results in erroneous assignments to the property in strict mode to be ignored rather than causing an exception to be thrown.

仕様は、互換性の理由から要求されない限り, `LenientSetter$x を利用する~SHOULD_NOT。 ~pageにて、作者が当の~propへの代入ingにより~IDL属性を~polyfillしようと試みていて、~propが存在するときでも不用意にそうしたとする。 ~strict-mode下では、これは例外を投出させ,~pageを壊すことになりかねない。 `LenientSetter$x が無いと、このことから~browserは,将来に出荷できなくなる。 ◎ Specifications SHOULD NOT use [LenientSetter] unless required for compatibility reasons. Pages have been observed where authors have attempted to polyfill an IDL attribute by assigning to the property, but have accidentally done so even if the property exists. In strict mode, this would cause an exception to be thrown, potentially breaking page. Without [LenientSetter], this could prevent a browser from shipping the feature.

これを将来に利用したいと望む仕様~策定者は、`論ML^。 ◎ Specification authors who wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

`LenientSetter$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `読専$の`正則~属性$以外に利用されては~MUST_NOT。
  • 同じ属性~上で, `PutForwards$x / `Replaceable$x 拡張属性と併用されては~MUST_NOT。
◎ The [LenientThis] extended attribute MUST take no arguments. It MUST NOT be used on anything other than a read only regular attribute. ◎ An attribute with the [LenientSetter] extended attribute MUST NOT also be declared with the [PutForwards] or [Replaceable] extended attributes.

`LenientSetter$x がどう実装されるかの詳細は、下の 属性 節に。 ◎ See the Attributes section below for how [LenientSetter] is to be implemented.

次の~IDL片は `LenientSetter$x 拡張属性を利用する~ifcを定義する。 ◎ The following IDL fragment defines an interface that uses the [LenientSetter] extended attribute.

interface Example {
  [LenientSetter] readonly attribute DOMString x;
  readonly attribute DOMString y;
};

この~ifcを~supportする~JS実装は, `x^M に対応する~accessor~prop上に設定子を持つことになり、~strict-mode下では,どのような代入も無視されるようになる。 ◎ An ECMAScript implementation that supports this interface will have a setter on the accessor property that correspond to x, which allows any assignment to be ignored in strict mode.

"use strict";

var example = getExample();  // `Example^T の~instanceを取得する。

// ~~問題ない。~strict-mode下では,何もしない設定子がある。
example.x = 1;

// `TypeError^t が投出される。~strict-mode下にあり,設定子がないので。
example.y = 1;

4.3.10. `LenientThis^x

`LenientThis$x `拡張属性$が `正則~属性$上に現れた場合、その属性が現れる`~ifc$を実装する~objとは異なる `this^v 値を伴うような,その属性の取得子や設定子の呼出は、無視されることになる。 ◎ If the [LenientThis] extended attribute appears on a regular attribute, it indicates that invocations of the attribute’s getter or setter with a this value that is not an object that implements the interface on which the attribute appears will be ignored.

`LenientThis$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `静的~属性$上に利用されては~MUST_NOT。
◎ The [LenientThis] extended attribute MUST take no arguments. It MUST NOT be used on a static attribute.

互換性の理由から要求されない限り、仕様は `LenientThis$x を利用する~SHOULD_NOT。 この特色機能を要する仕様~策定者は、`論ML^。 ◎ Specifications SHOULD NOT use [LenientThis] unless required for compatibility reasons. Specification authors who wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

`LenientThis$x がどう実装されるかについては、下の 属性 の節に。 ◎ See the Attributes section below for how [LenientThis] is to be implemented.

次の~IDL片は `LenientThis$x 拡張属性を利用する ~ifcを定義する。 ◎ The following IDL fragment defines an interface that uses the [LenientThis] extended attribute.

interface Example {
  [LenientThis] attribute DOMString x;
  attribute DOMString y;
};

この~ifcを~supportする~JS実装では、 x に対応する~accessor~propの取得子/設定子では, `Example^T ~obj以外の何かを伴う呼出しも許容されることになる。 ◎ An ECMAScript implementation that supports this interface will allow the getter and setter of the accessor property that corresponds to x to be invoked with something other than an Example object.

var example = getExample();  // `Example^T の~instanceを取得する。
var obj = { };

/* ~~通常。 */
example.x;

/* この値は `Example^T ~objでなく, かつ
   `LenientThis^x が利用されているので、無視される。 */
Object.getOwnPropertyDescriptor(Example.prototype, "x").get.call(obj);

/* `Example.prototype^v は `Example^T ~objでなく, かつ
   `LenientThis^x が利用されているので、これも無視される。 */
Example.prototype.x;

/* `Example.prototype^v は `Example^T ~objでないので `TypeError^t が投出される。 */
Example.prototype.y;

4.3.11. `NamedConstructor^x

`NamedConstructor$x `拡張属性$が `~ifc$上に現れた場合、~JS大域~objは,次を伴う~propを持つことになる:

  • その名前は、拡張属性の引数に指定された名前。
  • 値は、その~ifcを実装する~objを作成できる構築子~関数。

所与の~ifc上に,複数の `NamedConstructor$x 拡張属性が現れてもよい。

◎ If the [NamedConstructor] extended attribute appears on an interface, it indicates that the ECMAScript global object will have a property with the specified name whose value is a constructor function that can create objects that implement the interface. Multiple [NamedConstructor] extended attributes may appear on a given interface.

`NamedConstructor$x 拡張属性は: ◎ ↓

  • `識別子を引数にとる$か, または`有名~引数~listを引数にとる$ことが~REQUIRED。 前者の形 [NamedConstructor=`identifier$g] は、空の引数~list [NamedConstructor=`identifier$g()] を利用するのと同じ意味になる。 ~ifc上の各 `NamedConstructor$x 拡張属性が、[[ 前述の~propの値である構築子~関数 ]に,指定された引数を渡して、その~ifcを実装する~objを構築する仕方 ]を供することになる。 ◎ The [NamedConstructor] extended attribute MUST either take an identifier or take a named argument list. The first form, [NamedConstructor=identifier], has the same meaning as using an empty argument list, [NamedConstructor=identifier()]. For each [NamedConstructor] extended attribute on the interface, there will be a way to construct an object that implements the interface by passing the specified arguments to the constructor function that is the value of the aforementioned property.
  • 次に挙げる識別子は、有名~構築子の識別子として利用されては~MUST_NOT:

    • 別の~ifc上の `NamedConstructor$x 拡張属性の識別子
    • `~ifc~obj$を持つ~ifcの識別子
    • `予約済み識別子$
    ◎ The identifier used for the named constructor MUST NOT be the same as that used by an [NamedConstructor] extended attribute on another interface, MUST NOT be the same as an identifier of an interface that has an interface object, and MUST NOT be one of the reserved identifiers.
  • `呼戻~ifc$上に利用されては~MUST_NOT。 ◎ The [NamedConstructor] extended attribute MUST NOT be used on a callback interface.

有名~構築子がどう実装されるかの詳細は `named-constructors$sec に。 ◎ See section 4.6.2 below for details on how named constructors are to be implemented.

次の~IDLは `NamedConstructor$x 拡張属性を利用する~ifcを定義する。 ◎ The following IDL defines an interface that uses the [NamedConstructor] extended attribute.

[NamedConstructor=Audio,
 NamedConstructor=Audio(DOMString src)]
interface HTMLAudioElement : HTMLMediaElement {
  // ...
};

この~ifcを~supportする~JS実装は、 `Audio^T 構築子を利用する `HTMLAudioElement^T ~objの構築を許容することになる。 ◎ An ECMAScript implementation that supports this interface will allow the construction of HTMLAudioElement objects using the Audio constructor.

typeof Audio;                   // 

var a1 = new Audio();
   /* 引数なしの構築子を利用して,
   `HTMLAudioElement^T を実装する ~objを作成する。 */

var a2 = new Audio('a.flac');
   /* 1引数の構築子を利用して, `HTMLAudioElement^T を作成する。 */

4.3.12. `NewObject^x

`NewObject$x `拡張属性$が[ `正則~演算$/`静的~演算$ ]上に現れた場合、その演算が~callされる際に,常に 新たに作成された~objへの参照が返され~MUSTことを指示する。 ◎ If the [NewObject] extended attribute appears on a regular or static operation, then it indicates that when calling the operation, a reference to a newly created object MUST always be returned.

`NewObject$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。 ◎ The [NewObject] extended attribute MUST take no arguments.
  • `返値型$が[ `~ifc型$, または `~promise型$ ]である[ `正則~演算$/`静的~演算$ ]以外の所に利用されては~MUST_NOT。 ◎ The [NewObject] extended attribute MUST NOT be used on anything other than a regular or static operation whose return type is an interface type or a promise type.

この拡張属性の利用が適する一例には, `Document^T ~ifc( `DOM$r, 6.5 節)上の createElement 演算がある。 これは,~callされる度に新たな~objが返されるべきなので。 ◎ As an example, this extended attribute is suitable for use on the createElement operation on the Document interface ([DOM], section 6.5), since a new object should always be returned when it is called.

interface Document : Node {
  [NewObject] Element createElement(DOMString localName);
  ...
};

4.3.13. `NoInterfaceObject^x

`NoInterfaceObject$x `拡張属性$が `~ifc$上に現れた場合、その~ifcに対応する`~ifc~obj$は,~JS言語束縛には存在しないことになる。 ◎ If the [NoInterfaceObject] extended attribute appears on an interface, it indicates that an interface object will not exist for the interface in the ECMAScript binding.

`NoInterfaceObject$x 拡張属性は、明白な Web 互換性の理由がない限り,もっぱら`追補~ifc$として利用されるもの以外の~ifcには、利用される~SHOULD_NOT。 この特色機能を要する仕様~策定者は、`論ML^。 ◎ The [NoInterfaceObject] extended attribute SHOULD NOT be used on interfaces that are not solely used as supplemental interfaces, unless there are clear Web compatibility reasons for doing so. Specification authors who wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

`NoInterfaceObject$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。 ◎ The [NoInterfaceObject] extended attribute MUST take no arguments.
  • 同じ~ifc上で, `Constructor$x 拡張属性と併用されては~MUST_NOT。 一方, `NamedConstructor$x 拡張属性との併用は差し支えない。 ◎ If the [NoInterfaceObject] extended attribute is specified on an interface, then the [Constructor] extended attribute MUST NOT also be specified on that interface. A [NamedConstructor] extended attribute is fine, however.
  • `静的~演算$が定義されている~ifc上に指定されては~MUST_NOT。 ◎ The [NoInterfaceObject] extended attribute MUST NOT be specified on an interface that has any static operations defined on it.
  • `定数$が宣言されてる場合を除き,`呼戻~ifc$上に指定されては~MUST_NOT。 `定数$を伴わない呼戻~ifcは,`~ifc~obj$を決して持たないので。 ◎ The [NoInterfaceObject] extended attribute MUST NOT be specified on a callback interface unless it has a constant declared on it. This is because callback interfaces without constants never have interface objects.
  • この拡張属性が指定されていない~ifcが,この拡張属性が指定されている~ifcを継承しては~MUST_NOT ◎ An interface that does not have the [NoInterfaceObject] extended attribute specified MUST NOT inherit from an interface that has the [NoInterfaceObject] extended attribute specified.

`NoInterfaceObject$x の利用に課される固有の要件については、`es-interface$secに。 ◎ See section 4.2.20 for the specific requirements that the use of [NoInterfaceObject] entails.

次の`~IDL片$は2つの~ifcを定義する。 1つはその~ifc~objが~JS大域~obj上に公開され,もう1つはそうでない: ◎ The following IDL fragment defines two interfaces, one whose interface object is exposed on the ECMAScript global object, and one whose isn’t:

interface Storage {
  void addEntry(unsigned long key, any value);
};

[NoInterfaceObject]
interface Query {
  any lookupEntry(unsigned long key);
};

上の~IDLの~JS実装においては、 `Storage^T に対する原型の操作は許容される一方, `Query^T に対してはそうならない。 ◎ An ECMAScript implementation of the above IDL would allow manipulation of Storage’s prototype, but not Query’s.

typeof Storage;                        // `object^l に評価される。

// `Storage.addEntry^c に~trace用の `alert()^c ~callを追加する
var fn = Storage.prototype.addEntry;
Storage.prototype.addEntry = function(key, value) {
  alert('Calling addEntry()');
  return fn.call(this, key, value);
};

typeof Query;                          // `undefined^l に評価される。
var fn = Query.prototype.lookupEntry;  // 例外を投出。 `Query^T は定義されていない。

4.3.14. `OverrideBuiltins^x

`OverrideBuiltins$x `拡張属性$が `~ifc$上に現れた場合,その~ifcを実装する`~platform~obj$においては、[ その~objやその原型鎖 ]上に存在する他の~propに関わらず,~objの`被support~prop名$すべてに対し,それぞれに対応する~propがその~obj上に現れることになる。 このことは、(通例の挙動では、有名~propは[ ~obj自身やその原型鎖 ]上のどこにも同じ名前の~propが存在しないときに限り,公開されるのに対し、)有名~propが、[ さもなければ~obj上に現れることになる,同じ名前のどの~prop ]も,常に隠蔽することになることを意味する。 ◎ If the [OverrideBuiltins] extended attribute appears on an interface, it indicates that for a platform object implementing the interface, properties corresponding to all of the object’s supported property names will appear to be on the object, regardless of what other properties exist on the object or its prototype chain. This means that named properties will always shadow any properties that would otherwise appear on the object. This is in contrast to the usual behavior, which is for named properties to be exposed only if there is no property with the same name on the object itself or somewhere on its prototype chain.

`OverrideBuiltins$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • `有名~prop取得子$を定義しない~ifc上に現れては~MUST_NOT。
  • `Global$x / `PrimaryGlobal$x 拡張属性と併用されては~MUST_NOT。
  • `部分的~ifc定義$上に指定される場合、その部分的~ifc定義は,~ifc定義の中で`有名~prop取得子$を定義する部分をなすもので~MUST。
◎ The [OverrideBuiltins] extended attribute MUST take no arguments and MUST NOT appear on an interface that does not define a named property getter or that also is declared with the [Global] or [PrimaryGlobal] extended attribute. If the extended attribute is specified on a partial interface definition, then that partial interface definition MUST be the part of the interface definition that defines the named property getter.

`OverrideBuiltins$x の利用に課される固有の要件については `indexed-and-named-properties$sec, `defineownproperty$sec に。 ◎ See section 4.8.1 and section 4.8.7 for the specific requirements that the use of [OverrideBuiltins] entails.

次の`~IDL片$は2つの`~ifc$を定義する。 一方は`有名~prop取得子$を持ち, 他方はそうでない: ◎ The following IDL fragment defines two interfaces, one that has a named property getter and one that does not.

interface StringMap {
  readonly attribute unsigned long length;
  getter DOMString lookup(DOMString key);
};

[OverrideBuiltins]
interface StringMap2 {
  readonly attribute unsigned long length;
  getter DOMString lookup(DOMString key);
};

これら2つの~ifcの~JS実装においては、それぞれの~ifcを実装する~obj上の一部の~propについて,その取得による結果が異なってくることになる: ◎ In an ECMAScript implementation of these two interfaces, getting certain properties on objects implementing the interfaces will result in different values:

/* `StringMap^T の~instanceを得る。被support~prop名
   として, `abc^l, `length^l, `toString^l を持つとする。 */
var map1 = getStringMap();

/* 有名~prop取得子を呼出す。 */
map1.abc;

/* `length^M 属性に対応する~obj上の `length^l ~propを取りに行く。 */
map1.length;

/* ~objの原型鎖~上の `toString^l ~propを取りに行く。 */
map1.toString;


/* `StringMap2^T の~instanceを得る。これも被support~prop名
   として, `abc^l, `length^l, `toString^l を持つとする。 */
var map2 = getStringMap2();  

/* これは 有名~prop取得子を呼出す。 */
map2.abc;

/* これも 有名~prop取得子を呼出す。~obj上の
   `length^l ~propが length 属性に対応しているにも関わらず。 */
map2.length;

/* これもまた 有名~prop取得子を呼出す。 `toString^l が
   %map2 の prototype chain 内にある~propであるにも関わらず。 */
map2.toString;

4.3.15. `PutForwards^x

`PutForwards$x `拡張属性$が[ `~ifc型$の`読専$の`正則~属性$宣言 ]上に現れた場合、その属性への代入ingは 固有の挙動を持つことになる。 すなわち,その代入は、代入-が試みられた属性から,現在~参照されている~objの属性(その拡張属性の引数で指定される)に “転送-” される。 ◎ If the [PutForwards] extended attribute appears on a read only regular attribute declaration whose type is an interface type, it indicates that assigning to the attribute will have specific behavior. Namely, the assignment is “forwarded” to the attribute (specified by the extended attribute argument) on the object that is currently referenced by the attribute being assigned to.

`PutForwards$x 拡張属性には、`識別子を引数にとる$ことが~REQUIRED。 次が与えられるとき: ◎ The [PutForwards] extended attribute MUST take an identifier. Assuming that:

  • %A は `PutForwards$x 拡張属性が現れる`属性$, ◎ A is the attribute on which the [PutForwards] extended attribute appears,
  • %I は %A が宣言されている`~ifc$, ◎ I is the interface on which A is declared,
  • %J は %A の型として宣言されている `~ifc型$, ◎ J is the interface type that A is declared to be of, and
  • %N は その拡張属性の`識別子$引数, ◎ N is the identifier argument of the extended attribute,

このとき,`識別子$ %N を持つ別の`属性$ %B が %J 上に宣言されてい~MUST。 %I を実装している~obj上の属性 %A への値の代入では、代わりに, %A が参照する~objの属性 %B にその値が代入されることになる。 ◎ then there MUST be another attribute B declared on J whose identifier is N. Assignment of a value to the attribute A on an object implementing I will result in that value being assigned to attribute B of the object that A references, instead.

`PutForwards$x 注釈付きの`属性$は連鎖し得ることに注意。 すなわち、 `PutForwards$x `拡張属性$を伴う属性は,この拡張属性を持つ他の属性を指すことができる。 ただし、この代入の連鎖が循環しては~MUST_NOT。 代入の連鎖が辿られる際に,1つの`~ifc$上の特定0の属性に複数~回 遭遇するならば、循環が存在する。 ◎ Note that [PutForwards]-annotated attributes can be chained. That is, an attribute with the [PutForwards] extended attribute can refer to an attribute that itself has that extended attribute. There MUST NOT exist a cycle in a chain of forwarded assignments. A cycle exists if, when following the chain of forwarded assignments, a particular attribute on an interface is encountered more than once.

`PutForwards$x 拡張属性は: ◎ ↓

  • 同じ属性~上で, `LenientSetter$x / `Replaceable$x 拡張属性と併用されては~MUST_NOT。 ◎ An attribute with the [PutForwards] extended attribute MUST NOT also be declared with the [LenientSetter] or [Replaceable] extended attributes.
  • `読専$でない`属性$~上に利用されては~MUST_NOT。 ◎ The [PutForwards] extended attribute MUST NOT be used on an attribute that is not read only.
  • `静的~属性$上に利用されては~MUST_NOT。 ◎ The [PutForwards] extended attribute MUST NOT be used on a static attribute.
  • `呼戻~ifc$上で宣言される属性~上に利用されては~MUST_NOT。 ◎ The [PutForwards] extended attribute MUST NOT be used on an attribute declared on a callback interface.

`PutForwards$x がどう実装されるかについては、下の 属性 の節に。 ◎ See the Attributes section below for how [PutForwards] is to be implemented.

次の`~IDL片$は、姓名と人を表す~ifcを定義する。 `Person^T ~ifcの `name^M 属性~上に利用される `PutForwards$x 拡張属性は、その属性への代入による結果が `Person^T ~objの 【 `name^M 属性が指す `Name^T ~objの 】 `full^M 属性への代入になることを指示する: ◎ The following IDL fragment defines interfaces for names and people. The [PutForwards] extended attribute is used on the name attribute of the Person interface to indicate that assignments to that attribute result in assignments to the full attribute of the Person object:

interface Name {
  attribute DOMString full;
  attribute DOMString family;
  attribute DOMString given;
};

interface Person {
  [PutForwards=full] readonly attribute Name name;
  attribute unsigned short age;
};

~JS言語束縛においては、 `name^l ~propへの代入が許容されることになる: ◎ In the ECMAScript binding, this would allow assignments to the “name” property:

var p = getPerson();           // `Person^T の~instanceを得る。

p.name = 'John Citizen';       // この文は...
p.name.full = 'John Citizen';  // ...これと同じ挙動になる。

4.3.16. `Replaceable^x

`Replaceable$x `拡張属性$が `読専$の`正則~属性$上に現れた場合、`~platform~obj$上の対応する~propが設定される際に、その~obj上に,代入される値をとる同じ名前の自前の~propが作成されることになる。 この~propは、 `~ifc原型~obj$上に存在する,その属性に対応する~accessor~propを隠蔽する。 ◎ If the [Replaceable] extended attribute appears on a read only regular attribute, it indicates that setting the corresponding property on the platform object will result in an own property with the same name being created on the object which has the value being assigned. This property will shadow the accessor property corresponding to the attribute, which exists on the interface prototype object.

`Replaceable$x 拡張属性は: ◎ ↓

  • `引数をとらない$ことが~REQUIRED。 ◎ The [Replaceable] extended attribute MUST take no arguments.
  • 同じ属性~上で, `LenientSetter$x / `Replaceable$x 拡張属性と併用されては~MUST_NOT。 ◎ An attribute with the [Replaceable] extended attribute MUST NOT also be declared with the [LenientSetter] or [PutForwards] extended attributes.
  • `読専$でない`属性$~上に利用されては~MUST_NOT。 ◎ The [Replaceable] extended attribute MUST NOT be used on an attribute that is not read only.
  • `静的~属性$上に利用されては~MUST_NOT。 ◎ The [Replaceable] extended attribute MUST NOT be used on a static attribute.
  • `呼戻~ifc$上で宣言される属性に利用されては~MUST_NOT。 ◎ The [Replaceable] extended attribute MUST NOT be used on an attribute declared on a callback interface.

`Replaceable$x の利用に課される固有の要件については `es-attributes$sec に。 ◎ See section 4.6.6 for the specific requirements that the use of [Replaceable] entails.

次の`~IDL片$は、計数を増やす`演算$と,計数~値を公開する初期~値 0 の`属性$を持つ`~ifc$を定義する: ◎ The following IDL fragment defines an interface with an operation that increments a counter, and an attribute that exposes the counter’s value, which is initially 0:

interface Counter {
  [Replaceable] readonly attribute unsigned long value;
  void increment();
};

`Counter^T を実装する `~platform~obj$上の `value^l ~propへの代入ingにより,その`属性$に対応する~propは隠蔽されることになる: ◎ Assigning to the “value” property on a platform object implementing Counter will shadow the property that corresponds to the attribute:

var counter = getCounter();         // `Counter^T の~instanceを得る。
counter.value;                      // `0^v に評価される。

counter.hasOwnProperty("value");    // 
Object.getPrototypeOf(counter).hasOwnProperty("value");
                                    // 

counter.increment();
counter.increment();
counter.value;                      // `2^v に評価される。

counter.value = 'a';                
       // `Counter::value^V に関係無いもので~propを隠蔽する。

counter.hasOwnProperty("value");    // 

counter.increment();
counter.value;                      // `a^l に評価される。

delete counter.value;               // 元の~propを露にする。
counter.value;                      // `3^v に評価される。

4.3.17. `SameObject^x

`SameObject$x `拡張属性$が `読専$`属性$に現れた場合、所与の~obj上でその属性の値が取得される度に,常に同じ値が返され~MUSTことを指示する。 ◎ If the [SameObject] extended attribute appears on a read only attribute, then it indicates that when getting the value of the attribute on a given object, the same value MUST always be returned.

`SameObject$x 拡張属性は: ◎ ↓

  • `引数をとらない$ことが~REQUIRED。 ◎ The [SameObject] extended attribute MUST take no arguments.
  • [[ `~ifc型$/`~obj型$ ]である`読専$`属性$ ]以外の所に利用されては~MUST_NOT。 ◎ The [SameObject] extended attribute MUST NOT be used on anything other than a read only attribute whose type is an interface type or object.

この拡張属性の利用が適する一例には, `Document^T ~ifc( `DOM$r, 6.5 節)上の `implementation^c 属性がある。 所与の `Document^T ~objに対しては,常に同じ~objが返されるので。 ◎ As an example, this extended attribute is suitable for use on the implementation attribute on the Document interface ([DOM], section 6.5), since the same object is always returned for a given Document object.

interface Document : Node {
  [SameObject] readonly attribute DOMImplementation implementation;
  ...
};

4.3.18. `SecureContext^x

`SecureContext$x `拡張属性$が[[ `~ifc$ / `部分的~ifc定義$ ]/ 個々の`~ifc~mb$ ] %X 上に現れた場合、 %X は `保安的~文脈$( `SECURE-CONTEXTS$r, 2 節)の中でのみ公開されることを指示する。 ◎ If the [SecureContext] extended attribute appears on an interface, partial interface, an individual interface member, it indicates that the interface or interface member is exposed only within a secure context ([SECURE-CONTEXTS], section 2).

`SecureContext$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。 ◎ The [SecureContext] extended attribute MUST take no arguments.
  • [[ `~ifc$ / `部分的~ifc定義$ ]/ 個々の`~ifc~mb$ ]以外のものに利用されては~MUST_NOT。 ◎ The [SecureContext] extended attribute MUST NOT be used on anything other than an interface, partial interface, or an individual interface member.

[ `SecureContext$x `拡張属性$を指定できるような ]構成子 %X が `保安的~文脈~下に限り可用@ になるかどうかは、次に従って定義される: ◎ Whether a construct that the [SecureContext] extended attribute can be specified on is available only in secure contexts is defined as follows:

  • %X に `SecureContext$x `拡張属性$が指定されているならば、 %X は,`保安的~文脈~下に限り可用$になる。 ◎ If the [SecureContext] extended attribute is specified on the construct, then it is available only in secure contexts.
  • 指定されていない場合に %X が`保安的~文脈~下に限り可用$になるかどうかは、 %X の型に依存する: ◎ Otherwise, if the [SecureContext] extended attribute does not appear on a construct, then whether it is available only in secure contexts depends on the type of construct:

    ~ifc
    %X は,`保安的~文脈~下に限り可用$ではない。 ◎ The interface or dictionary is not available only in secure contexts.
    部分的~ifc
    %X が`保安的~文脈~下に限り可用$になるのは、元の~ifc定義がそうであるとき,そのときに限る。 ◎ The partial interface is available only in secure contexts if and only if the original interface definition is.
    ~ifc~mb
    %X が`保安的~文脈~下に限り可用$になるのは、 %X を宣言している[ ~ifc/部分的~ifc定義 ]がそうであるとき,そのときに限る。 ◎ The interface member is available only in secure contexts if and only if the interface or partial interface the member is declared on is.

構成子が`保安的~文脈~下に限り可用$になるかどうかは、所与の~JS大域環境にて`公開され$るかどうかに波及する。 ◎ Whether a construct is available only in secure contexts influences whether it is exposed in a given ECMAScript global environment.

`SecureContext$x 拡張属性は:

  • `多重定義$されている`演算$上に現れるならば,他のすべての多重定義~上にも現れ~MUST。 ◎ If [SecureContext] appears on an overloaded operation, then it MUST appear on all overloads.
  • [ ~ifc~mbと, その~ifc~mbを宣言している[ ~ifc/部分的~ifc定義 ]]の両者に指定されては~MUST_NOT。 ◎ The [SecureContext] extended attribute MUST NOT be specified on both an interface member and the interface or partial interface definition the interface member is declared on.
  • ~ifc上に現れるならば、それを`継承-$するどの~ifc上にも現れ~MUST。 ◎ An interface without the [SecureContext] extended attribute MUST NOT inherit from another interface that does specify [SecureContext].

次の`~IDL片$は、すべての文脈で実行可能な 1 個の`演算$, および 保安的~文脈からのみ実行可能な 1 個の演算と 1 個の属性を伴う~ifcを定義する: ◎ The following IDL fragment defines an interface with one operation that is executable from all contexts, and two which are executable only from secure contexts.

interface PowerfulFeature {
/* 次の演算の~callはどの文脈~下でも成功する。 */
  Promise <Result> calculateNotSoSecretResult();

/* 保安的でない文脈~下では、次の演算は公開されなくなる。
`PowerfulFeature.prototype^c 上に
`calculateSecretResult^l ~propはない。 */
  [SecureContext] Promise<Result> calculateSecretResult();

/* 次の属性にも同じことが言え、保安的でない文脈には公開されなくなる
— `PowerfulFeature.prototype^c 上に
`secretBoolean^l ~propはない。 */
  [SecureContext] readonly attribute boolean secretBoolean;
};

4.3.19. `TreatNonObjectAsNull^x

`TreatNonObjectAsNull$x `拡張属性$が `呼戻~関数$上に現れた場合、 `属性$に代入される[ `~nullable$`呼戻~関数$型であって, ~objではない ]どの値も, `null^V 値に変換するようにすることを指示する。 ◎ If the [TreatNonObjectAsNull] extended attribute appears on a callback function, then it indicates that any value assigned to an attribute whose type is a nullable callback function that is not an object will be converted to the null value.

仕様は、旧来の API の挙動の指定, もしくは それらの API との整合性が要求されていない限り, `TreatNonObjectAsNull$x を利用する~SHOULD_NOT。 この特色機能を要する仕様~策定者は、`論ML^。 この文書が書かれた時点での, `TreatNonObjectAsNull$x の妥当な既知の用途は、 `onclick^c, `onerror^c などの ~event-handler~IDL属性 ( `HTML5$r )の型として利用される`呼戻~関数$のみである。 ◎ Specifications SHOULD NOT use [TreatNonObjectAsNull] unless required to specify the behavior of legacy APIs or for consistency with these APIs. Specification authors who wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding. At the time of writing, the only known valid use of [TreatNonObjectAsNull] is for the callback functions used as the type of event handler IDL attributes ([HTML5], section 6.1.6.1) such as onclick and onerror.

`TreatNonObjectAsNull$x の利用に課される固有の要件については `es-nullable-type$sec に。 ◎ See section 4.2.24 for the specific requirements that the use of [TreatNonObjectAsNull] entails.

次の`~IDL片$は、 `TreatNonObjectAsNull$x 注釈付きの`呼戻~関数$型の属性と, この`拡張属性$を伴わない`呼戻~関数$を持つ~ifcを定義する。 ◎ The following IDL fragment defines an interface that has one attribute whose type is a [TreatNonObjectAsNull]-annotated callback function and another whose type is a callback function without the extended attribute:

callback OccurrenceHandler = void (DOMString details);

[TreatNonObjectAsNull]
callback ErrorHandler = void (DOMString details);

interface Manager {
  attribute OccurrenceHandler? handler1;
  attribute ErrorHandler? handler2;
};

~JS実装においては、 `handler1^c に対する~objでない値( `Number^t 値など)の代入ingは, `handler2^c に対する代入ingの挙動と異なる: ◎ In an ECMAScript implementation, assigning a value that is not an object (such as a Number value) to handler1 will have different behavior from that when assigning to handler2:

var manager = getManager();  // `Manager^T の~instanceを取得する。

manager.handler1 = function() { };
manager.handler1;            // 

try {
  manager.handler1 = 123;    // `TypeError^t を投出。
} catch (e) {
}

manager.handler2 = function() { };
manager.handler2;            // 

manager.handler2 = 123;
manager.handler2;            // `null^v に評価される。

4.3.20. `TreatNullAs^x

`TreatNullAs$x `拡張属性$が[ `DOMString$T 型の[ `属性$ / `演算$の引数 ]]上に現れた場合、[ その属性に代入される / その演算の引数に渡される ] `null^v 値は、既定による `null^l に文字列化される代わりに,空~文字列 "" に変換されることになる。 ◎ If the [TreatNullAs] extended attribute appears on an attribute or operation argument whose type is DOMString, it indicates that a null value assigned to the attribute or passed as the operation argument will be handled differently from its default handling. Instead of being stringified to “null”, which is the default, it will be converted to the empty string “”.

`TreatNullAs$x が演算~自身に指定されていて,その演算が`呼戻~ifc$上にある場合、その ~ifcを実装する利用者~obj においてその演算を実装する関数の返値は、上述の演算~引数や属性に対するときと同じ仕方で取扱われることになる。 ◎ If [TreatNullAs] is specified on an operation itself, and that operation is on a callback interface, then it indicates that a user object implementing the interface will have the return value of the function that implements the operation handled in the same way as for operation arguments and attributes, as above.

`TreatNullAs$x 拡張属性は: ◎ ↓

  • 次の`識別子を引数にとる$ことが~REQUIRED: `EmptyString^c ◎ The [TreatNullAs] extended attribute MUST take the identifier EmptyString.
  • `DOMString$T でない演算~引数, 属性, 演算の返値に指定されては~MUST_NOT。 ◎ The [TreatNullAs] extended attribute MUST NOT be specified on an operation argument, attribute or operation return value whose type is not DOMString.

    すなわち、 `DOMString?^T 型の属性であっても, `null^V はその型の妥当な値なので `TreatNullAs$x が利用されてはならない。 ◎ This means that even an attribute of type DOMString? must not use [TreatNullAs], since null is a valid value of that type.

  • 非~呼戻~ifc上の演算に指定されては~MUST_NOT ◎ The [TreatNullAs] extended attribute also MUST NOT be specified on an operation on a non-callback interface.

`TreatNullAs$x の利用に課される固有の要件については `es-DOMString$sec に。 ◎ See section 4.2.16 for the specific requirements that the use of [TreatNullAs] entails.

次の`~IDL片$は、 `TreatNullAs$x 拡張属性を伴う属性と同じ拡張属性を伴う引数をとる演算を持つ,~ifcを定義する。 ◎ The following IDL fragment defines an interface that has one attribute with the [TreatNullAs] extended attribute, and one operation with an argument that has the extended attribute:

interface Dog {
  attribute DOMString name;
  [TreatNullAs=EmptyString] attribute DOMString owner;

  boolean isMemberOfBreed([TreatNullAs=EmptyString] DOMString breedName);
};

`Dog^T ~ifcを実装する~JS実装においては、 `owner^l ~propに代入される, あるいは `isMemberOfBreed^c 関数の引数に渡される `null^v 値は、 `null^l ではなく,空~文字列に変換されることになる: ◎ An ECMAScript implementation implementing the Dog interface would convert a null value assigned to the “owner” property or passed as the argument to the isMemberOfBreed function to the empty string rather than "null":

var d = getDog();         
       // %d は `Dog^T ~ifcを実装する~platform~objとする。

d.name = null;            // 文字列 `null^l を `.name^c ~propに代入する。

d.owner = null;           // 文字列 "" を `.owner^c ~propに代入する。

d.isMemberOfBreed(null);  // 文字列 "" を `isMemberOfBreed^c 関数に渡す。

4.3.21. `Unforgeable^x

`Unforgeable$x `拡張属性$が[ 静的でない[ `属性$/`演算$ ]]上に現れた場合、その属性/演算は,[ その挙動を改変できない, かつ[ ~obj上で~prop検索が遂行された際には,常にその属性の~prop値が返される ]]ような~JS~propとして反映されることになる。 特に,その~propは、非~configurableになり,かつ[ ~objの原型~上ではなく, ~obj上の自前の~prop ]として存在することになる。 ◎ If the [Unforgeable] extended attribute appears on a non-static attribute or non-static operations, it indicates that the attribute or operation will be reflected as an ECMAScript property in a way that means its behavior cannot be modified and that performing a property lookup on the object will always result in the attribute’s property value being returned. In particular, the property will be non-configurable and will exist as an own property on the object itself rather than on its prototype.

`Unforgeable$x `拡張属性$が `~ifc$上に現れた場合、その~ifcのどの`広義~帰結~ifc$上で宣言されている どの[ 静的でない[ `属性$/`演算$ ] ]も、その原型~上ではなく, その~ifcを実装する~obj上の自前の~JS~propとして,上述と同様に反映されることになる。 ◎ If the [Unforgeable] extended attribute appears on an interface, it indicates that all of the non-static attributes and non-static operations declared on that interface and its consequential interfaces will be similarly reflected as own ECMAScript properties on objects that implement the interface, rather than on the prototype.

属性/演算 %m は、次のいずれかが成立するとき, 所与の~ifc %A 上において `偽装不可@ とされる: ◎ An attribute or operation is said to be unforgeable on a given interface A if any of the following are true:

  • %m は %A のいずれかの`広義~帰結~ifc$上にて, `Unforgeable$x `拡張属性$ 注釈付きで宣言されている ◎ The attribute or operation is declared on A or one of A’s consequential interfaces, and is annotated with the [Unforgeable] extended attribute.
  • `Unforgeable$x `拡張属性$ 注釈付きであるような %A の`広義~帰結~ifc$ %B が存在して, %m が %B のいずれかの`広義~帰結~ifc$上で宣言されている ◎ The attribute or operation is declared on A or one of A’s consequential interfaces, and that interface is annotated with the [Unforgeable] extended attribute. ◎ There exists an interface B, which is either A or one of A’s consequential interfaces, B is annotated with the [Unforgeable] extended attribute, and the attribute or operation is declared on one of B’s consequential interfaces.

`Unforgeable$x 拡張属性は:

  • `引数をとらない$ことが~REQUIRED。
  • [[ 静的でない[ `属性$, `演算$ ]], ~ifc ]以外の所に現れては~MUST_NOT。
  • 演算~上に現れた場合、その~ifc上で同じ識別子を持つ他のすべての演算~上にも現れ~MUST。
◎ The [Unforgeable] extended attribute MUST take no arguments. ◎ The [Unforgeable] extended attribute MUST NOT appear on anything other than an attribute, non-static operation or an interface. If it does appear on an operation, then it MUST appear on all operations with the same identifier on that interface.

属性/演算 %m が,~ifc %A 上で`偽装不可$であって, かつ %A が別の~ifc %B の`被継承~ifc$である場合、 %B の`広義~帰結~ifc$は,`識別子$が %m と同じであるような[静的でない属性]や`正則~演算$を持っては~MUST_NOT。 ◎ If an attribute or operation X is unforgeable on an interface A, and A is one of the inherited interfaces of another interface B, then B and all of its consequential interfaces MUST NOT have a non-static attribute or regular operation with the same identifier as X.

例えば,次は許容されない: ◎ For example, the following is disallowed:

interface A1 {
[Unforgeable] readonly attribute DOMString x;
};
interface B1 : A1 {
  void x();  
       // 妥当でない: `A1^T の `x^M で隠蔽されるので。
};

interface B2 : A1 { };
B2 implements Mixin;
interface Mixin {
  void x();  
       // 妥当でない: `B2^T における `x^M の複製は `A1^T の `x^M で隠蔽されるので。
};

[Unforgeable]
interface A2 {
  readonly attribute DOMString x;
};
interface B3 : A2 {
  void x();  
       // 妥当でない: `A2^T の `x^M で隠蔽されるので。
};

interface B4 : A2 { };
B4 implements Mixin;
interface Mixin {
  void x();  
       // 妥当でない: `B4^T における `x^M の複製は `A2^T の `x^M で隠蔽されるので。
};

interface A3 { };
A3 implements A2;
interface B5 : A3 {
  void x();  
       // 妥当でない: `A3^T における [ `A2^T の `x^M ]の mixed-in 複製で隠蔽されるので。
};

`Unforgeable$x の利用に課される固有の要件については `es-attributes$sec, `es-operations$sec, `es-platform-objects$sec, `indexed-and-named-properties$sec, `defineownproperty$sec に。 ◎ See section 4.6.6, section 4.6.7, section 4.8, section 4.8.1 and section 4.8.7 for the specific requirements that the use of [Unforgeable] entails.

次の`~IDL片$は 片方に `Unforgeable$x が指定された2個の`属性$を持つ~ifcを定義する: ◎ The following IDL fragment defines an interface that has two attributes, one of which is designated as [Unforgeable]:

interface System {
  [Unforgeable] readonly attribute DOMString username;
  readonly attribute long long loginTime; 
};

この~ifcの~JS実装においては、 `username^M 属性は,~obj自身において非~configurable~propとして公開されることになる: ◎ In an ECMAScript implementation of the interface, the username attribute will be exposed as a non-configurable property on the object itself:

var system = getSystem();         // `System^T の~instanceを取得する。

system.hasOwnProperty("username");             // 
system.hasOwnProperty("loginTime");            // 
System.prototype.hasOwnProperty("username");   // 
System.prototype.hasOwnProperty("loginTime");  // 

try {
  // この~callは失敗することになる — ~propは非~configurableなので。
  Object.defineProperty(system, "username", { value: "administrator" });
} catch (e) { }

// 次の `defineProperty^c ~callは成功する — `System.prototype.loginTime^c が~configurableなので。
var forgedLoginTime = 5;
Object.defineProperty(System.prototype, "loginTime", { value: forgedLoginTime });

system.loginTime;  // よって,これは今や %forgedLoginTime に評価される。

4.3.22. `Unscopable^x

`Unscopable$x `拡張属性$が[ `正則~属性$/`正則~演算$ ]上に現れた場合、[ その~ifc~mbを伴う~ifcを実装する~obj ]が,[ その~prop名 %N を,それに伴うどの[ ~obj環境 record ]内にも,その基底~objとして内包しない ]ことを指示する。 その~~結果、 `with^c 文の中では,[ %N に合致する “素の” 識別子 ]は,その~propには解決されないことになる。 このふるまいは、 %N を[ `~ifc原型~obj$上の `unscopables_symbol^ ~propの値 ]に含ませることで,得られる。 ◎ If the [Unscopable] extended attribute appears on a regular attribute or regular operation, it indicates that an object that implements an interface with the given interface member will not include its property name in any object environment record with it as its base object. The result of this is that bare identifiers matching the property name will not resolve to the property in a with statement. This is achieved by including the property name on the interface prototype object’s @@unscopables property’s value.

`Unscopable$x 拡張属性は: ◎ ↓

  • `引数をとらない$ことが~REQUIRED。 ◎ The [Unscopable] extended attribute MUST take no arguments.
  • [ `正則~属性$, `正則~演算$ ]以外の所に現れては~MUST_NOT。 ◎ The [Unscopable] extended attribute MUST NOT appear on anything other than a regular attribute or regular operation.

`Unscopable$x の利用に課される固有の要件については `interface-prototype-object$sec に。 ◎ See section 4.6.3 for the specific requirements that the use of [Unscopable] entails.

例えば、次の~IDLが与えられたとき: ◎ For example, with the following IDL:

interface Thing {
  void f();
  [Unscopable] g();
};

`f^l ~propは、 `with^c 文の中で “素の” 識別子により参照できるが, `g^l ~propはできない: ◎ the “f” property an be referenced with a bare identifier in a with statement but the “g” property cannot:

var thing = getThing();  // `Thing^T の~instance
with (thing) {
  f;                     // `Function^t ~objに評価される。
  g;                     // `ReferenceError^t を投出。
}

4.4. 保安~検査

以下の節の一部の~algoでは、所与の~objに対し `保安~検査を遂行する@† ものがある。 この検査は、所与の[ `演算$/`属性$ ] %f に対する[ 呼出/~access ]が許容されるべきかどうかを決定するために利用される。 保安~検査に対する入力は次の 4 つである: ◎ Certain algorithms in the sections below are defined to perform a security check on a given object. This check is used to determine whether a given operation invocation or attribute access should be allowed. The security check takes the following four inputs:

  1. [ %f の呼出 / %f への~access ]が行われている当の`~platform~obj$ ◎ the platform object on which the operation invocation or attribute access is being done,
  2. %f を実装する `Function^t ~obj %F が属する~JS大域環境†

    【† 簡潔に記述するため、この訳では,この入力には %F をそのまま渡すようにも記される。 その場合は、 %F が属する~JS大域環境が渡されたと解釈するものとする。 】

    ◎ the ECMAScript global environment associated with the Function object that implements the operation or attribute,
  3. %f の`識別子$ ◎ the identifier of the operation or attribute, and
  4. 次のいずれかで与えられる, %F の種別:

    • `~meth^C ( %f が演算に対応するとき)
    • `取得子^C ( %f が “取得子” 関数に対応するとき)
    • `設定子^C ( %f が “設定子” 関数に対応するとき)
    ◎ the type of the Function object – “method” (when it corresponds to an IDL operation), or “getter” or “setter” (when it corresponds to the getter or setter function of an IDL attribute).

どのようにして[ 保安~検査が遂行された上で,適切な例外を投出するか, 通常のように返るか ]については, HTML 仕様が定義するものと期待されている。 `HTML$r ◎ The expectation is that the HTML specification defines how a security check is performed, and that it will either throw an appropriate exception or return normally. [HTML]

4.5. 多重定義~解決~algo

多重定義された`関数類$の呼出を解決するために, `多重定義~解決~algo@ が定義される。 その入力は:

  • `有効~多重定義~集合$ %S
  • ~JS値の~list %arg0..%n−1

である。 その出力は,次の組である:

  • %S 内のいずれかの~entryの[ `演算$/`拡張属性$(構築子) ]
  • 各項が[ ~IDL値, または`MISSING^ ]のいずれかであるような,~list

~algoは次に従って挙動する:

◎ In order to define how overloaded function invocations are resolved, the overload resolution algorithm is defined. Its input is an effective overload set, S, and a list of ECMAScript values, arg0..n−1. Its output is a pair consisting of the operation or extended attribute of one of S’s entries and a list of IDL values or the special value “missing”. The algorithm behaves as follows:
  1. %maxarg := max( %S 内の各~entryの `ol-type-list^ の長さ ) ◎ Let maxarg be the length of the longest type list of the entries in S.
  2. %argcount :← min(%maxarg, %n) ◎ Initialize argcount to be min(maxarg, n).
  3. %S から[ `ol-type-list^の長さ ~NEQ %argcount ]なる~entryすべてを除去する ◎ Remove from S all entries whose type list is not of length argcount.
  4. ~IF %S ~EQ ∅ ~THEN ~THROW `TypeError^t ◎ If S is empty, then throw a TypeError.
  5. %d :← −1 ◎ Initialize d to −1.
  6. %method :← `undefined^v ◎ Initialize method to undefined.
  7. ~IF %S に複数の~entryがある ~THEN %d ← それらの %S の~entryに対する`判別引数~index$ ◎ If there is more than one entry in S, then set d to be the distinguishing argument index for the entries of S.
  8. %values :← 空~list(各項が[ ~IDL値, または`MISSING^ ]のいずれかになる) ◎ Initialize values to be an empty list, where each entry will be either an IDL value or the special value “missing”.
  9. %i :← 0 ◎ Initialize i to 0.
  10. ~WHILE %i < %d : ◎ While i < d:

    1. %V := %arg%i ◎ Let V be argi.
    2. %type := %S から任意に選んだ~entryの `ol-type-list^ の中の~index %i に位置する型 ◎ Let type be the type at index i in the type list of any entry in S.

      この時点では %S のすべての~entryにおいて,その~index %i に位置する[ `ol-type-list^ の型, および `ol-optionality-list^の`省略可否 値$ ]は 同じである。 【 (下で利用されている)既定~値も 同じになる必要がある ように思われるが? 】 ◎ All entries in S at this point have the same type and optionality value at index i.

    3. %optionality := %S から任意に選んだ~entryの `ol-optionality-list^ の中の~index %i に位置する`省略可否 値$ ◎ Let optionality be the value at index i in the list of optionality values of any entry in S.
    4. ~IF[ %optionality ~EQ “`省略可^C” ]~AND[ %V ~EQ `undefined^v ] ⇒ ◎ If optionality is “optional” and V is undefined, then:

      1. ~IF ~index %i に位置する引数は `既定~値$を伴って宣言されている ~THEN その既定~値を %values に付加する ◎ If the argument at index i is declared with a default value, then append to values that default value.
      2. ~ELSE ~THEN `MISSING^ を %values に付加する ◎ Otherwise, append to values the special value “missing”.
    5. ~ELSE ~THEN %V を~IDL型 %type に`toIDL^した結果を %values に付加する ◎ Otherwise, append to values the result of converting V to IDL type type.
  11. ~IF %i ~EQ %d 【すなわち, %S に複数の~entryがある】 ⇒ ◎ If i = d, then:

    1. %V := %arg%i ◎ Let V be argi.

      これが多重定義の解決-に利用されることになる引数になる。 ◎ This is the argument that will be used to resolve which overload is selected.

    2. ~IF[ %V ~EQ `undefined^v ]~AND[ %S の~entryに[ その `ol-optionality-list^ の中の~index %i に位置する`省略可否 値$ ] ~EQ “`省略可^C” なるものが在る ] ~THEN 他のすべての~entryを %S から除去する ◎ If V is undefined, and there is an entry in S whose list of optionality values has “optional” at index i, then remove from S all other entries.
    3. ~ELIF [ %V ~IN { `null^v, `undefined^v } ]~AND[ %S の~entryに[ その `ol-type-list^ の中の~index %i に位置する型が `~nullable型を内包する$ ]ようなものが在る ] ~THEN 他のすべての~entryを %S から除去する ◎ ↓
    4. ~ELIF 下の表の中に,次のいずれも満たすような行が在る:

      • %V は行の一列目の条件を満たす。
      • %S の~entryに,次を満たすものが在る:[ その `ol-type-list^ の中の~index %i に位置する型 %T ]は[ 行の二列目に挙げられる型の集合 %Types ]に型互換である。

      ~THEN 表の中のそのような行のうち,最初の行について、[ 上の二番目の条件に該当する %S の~entry† ]以外の~entryすべてを, %S から除去する

      ここで、型 %T が,(`~nullable$でも `共用体~型$ でもない)型の集合 %Types に 型互換 であるとは、 %T が次のいずれかを満たすことを意味する:

      • %T は %Types に属する
      • %T は`~nullable$型であり, かつ その`内縁~型$は %Types に属する
      • %T は`共用体~型$, または`~nullable$共用体~型である, かつ その`平坦化~mb型$の中に %Types に属するものが在る

      【† 下の表のどの行についても、二列目に挙げられた型たちは,どの 2 つも互いに`判別可能$でない。 したがって、 %S (`有効~多重定義~集合$), %i (`判別引数~index$)の定義により、どの行についても,`型互換$な %S の~entryは,高々1個になる。 】【 簡潔にするため、この段は,原文の記述を再構成している。 】

      %V が満たす条件 %Types
      %V ~IN { `null^v, `undefined^v } ◎ Otherwise: if V is null or undefined, and there is an entry in S that has one of the following types at position i of its type list, `辞書~型$ ◎ • a nullable type • a dictionary type • a union type that includes a nullable type or that has a dictionary type in its flattened members ◎ then remove from S all other entries.
      `~platform~obj$である ◎ Otherwise: if V is a platform object, and there is an entry in S that has one of the following types at position i of its type list, %V が実装する`~ifc型$, `object$T ◎ • an interface type that V implements • object • a nullable version of any of the above types • a union type or a nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `RegExp^t ~objである ◎ Otherwise: if V is a RegExp object and there is an entry in S that has one of the following types at position i of its type list, `RegExp$T, `object$T ◎ • RegExp • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries. ◎ *原文 重複
      `DOMException^t ~objである ◎ Otherwise: if V is a DOMException platform object and there is an entry in S that has one of the following types at position i of its type list, `DOMException$T, `Error$T, `object$T ◎ • DOMException • Error • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `Error^t ~objである(すなわち, `ErrorData^es `internal_slot^を持つ) ◎ Otherwise: if V is an Error object (that is, it has an [[ErrorData]] internal slot) and there is an entry in S that has one of the following types at position i of its type list, `Error$T, `object$T ◎ • Error • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `ArrayBufferData^es `internal_slot^を持つ ◎ Otherwise: if V is an object with an [[ArrayBufferData]] internal slot and there is an entry in S that has one of the following types at position i of its type list, `ArrayBuffer$T, `object$T ◎ • ArrayBuffer • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `DataView^es `internal_slot^を持つ ◎ Otherwise: if V is an object with a [[DataView]] internal slot and there is an entry in S that has one of the following types at position i of its type list, `DataView$T, `object$T ◎ • DataView • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `TypedArrayName^es `internal_slot^を持つ ◎ Otherwise: if V is an object with a [[TypedArrayName]] internal slot and there is an entry in S that has one of the following types at position i of its type list, [ 型~名が %V の `TypedArrayName^es `internal_slot^ に等しい `有型~配列~型$ ], `object$T ◎ • a typed array type whose name is equal to the value of V’s [[TypedArrayName]] internal slot • object • a nullable version of either of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `IsCallable$A( %V ) ~EQ ~true ◎ Otherwise: if IsCallable(V) is true, and there is an entry in S that has one of the following types at position i of its type list, `呼戻~関数$ 型, `object$T ◎ • a callback function type • object • a nullable version of any of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.

      [ ~native `RegExp^t ~objを除く任意の種類の~objである ]~AND[ 次を遂行した結果の %method ~NEQ `undefined^v ]:

      1. %method := `GetMethod$A( %V, `iterator_symbol^ ) の結果
      2. `ReturnIfAbrupt$A( %method )
      ◎ Otherwise: if V is any kind of object except for a native RegExp object, and there is an entry in S that has one of the following types at position i of its type list,
      `連列~型$, `凍結~配列~型$ ◎ • a sequence type • a frozen array type • a nullable version of any of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ and after performing the following steps, ◎ Let method be the result of GetMethod(V, @@iterator). ◎ ReturnIfAbrupt(method). ◎ method is not undefined, then remove from S all other entries.
      ~native `RegExp^t ~objを除く任意の種類の~objである ◎ Otherwise: if V is any kind of object except for a native RegExp object, and there is an entry in S that has one of the following types at position i of its type list, `呼戻~ifc$型, `辞書~型$, `object$T ◎ • a callback interface type • a dictionary type • object • a nullable version of any of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `Boolean^t 値である ◎ Otherwise: if V is a Boolean value, and there is an entry in S that has one of the following types at position i of its type list, `boolean$T ◎ • boolean • a nullable boolean • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      `Number^t 値である ◎ Otherwise: if V is a Number value, and there is an entry in S that has one of the following types at position i of its type list, `実数~型$ ◎ • a numeric type • a nullable numeric type • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      無条件 ◎ Otherwise: if there is an entry in S that has one of the following types at position i of its type list, `文字列~型$ ◎ • a string type • a nullable version of any of the above types • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      無条件 ◎ Otherwise: if there is an entry in S that has one of the following types at position i of its type list, `実数~型$ ◎ • a numeric type • a nullable numeric type • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      無条件 ◎ Otherwise: if there is an entry in S that has one of the following types at position i of its type list, `boolean$T ◎ • boolean • a nullable boolean • a union type or nullable union type that has one of the above types in its flattened member types ◎ then remove from S all other entries.
      無条件 ◎ Otherwise: if there is an entry in S that has any at position i of its type list, then remove from S all other entries. `any$T
    5. ~ELSE ~THEN ~THROW `TypeError^t ◎ Otherwise: throw a TypeError.
  12. %entry := %S の(~~唯一の)~entry ◎ ↓
  13. %callable := %entry の `ol-callable^ ( `演算$/`拡張属性$ ) ◎ Let callable be the operation or extended attribute of the single entry in S.
  14. ~IF[ %i ~EQ %d ]~AND[ %method ~NEQ `undefined^v ]⇒ ◎ If i = d and method is not undefined, then

    1. %V := %arg%i ◎ Let V be argi.
    2. %T := %entry の `ol-type-list^ の中の~index %i に位置する型 ◎ Let T be the type at index i in the type list of the remaining entry in S.
    3. ~IF %T は`連列~型$である ~THEN [ %V, %method ]から,型 %T の`連列~値を作成-$した結果を, %values に付加する ◎ If T is a sequence type, then append to values the result of creating a sequence of type T from V and method.
    4. ~ELSE( %T は`凍結~配列~型$である) ~THEN [ %V, %method ]から,型 %T の`凍結~配列~値を作成-$した結果を, %values に付加する ◎ Otherwise, T is a frozen array type. Append to values the result of creating a frozen array of type T from V and method.
  15. ~WHILE %i < %argcount : ◎ While i < argcount:

    1. %V := %arg%i ◎ Let V be argi.
    2. %type := %entry の `ol-type-list^ の中の~index %i に位置する型 ◎ Let type be the type at index i in the type list of the remaining entry in S.
    3. %optionality := %entry の `ol-optionality-list^ の中の~index %i に位置する`省略可否 値$ ◎ Let optionality be the value at index i in the list of optionality values of the remaining entry in S.
  16. ~WHILE %i < %callable が宣言している引数~個数: ◎ While i is less than the number of arguments callable is declared to take:

    1. ~IF %callable の~index %i に位置する引数に `既定~値$ が宣言されている ~THEN その既定~値を %values に付加する ◎ If callable’s argument at index i is declared with a default value, then append to values that default value.
    2. ~ELIF %callable の~index %i に位置する引数は`可変個~引数$でない ~THEN `MISSING^を %values に付加する ◎ Otherwise, if callable’s argument at index i is not variadic, then append to values the special value “missing”.
  17. ~RET ~pair <%callable, %values> ◎ Return the pair <callable, values>.

多重定義~解決~algoは、~callされている[ 多重定義された`関数類$ ]の識別に加えて、 ~JS引数~値から,それぞれに対応する~IDL値への変換を遂行する。 概略的には次のように演算する。 ◎ The overload resolution algorithm performs both the identification of which overloaded operation, constructor, etc. is being called, and the conversion of the ECMAScript argument values to their corresponding IDL values. Informally, it operates as follows.

まず、関数に渡された~JS引数の個数を考慮に入れつつ,妥当な多重定義の選定が行われる: ◎ First, the selection of valid overloads is done by considering the number of ECMAScript arguments that were passed in to the function:

  • 最長の多重定義~引数~listより多い引数が渡された場合、余分な引数は無視する。 ◎ If there are more arguments passed in than the longest overload argument list, then they are ignored.
  • 余分な引数を無視した後の引数の個数と,同じ個数の引数をとれる多重定義のみが考慮の対象になる。 もし無ければ, `TypeError^t が投出される。 ◎ After ignoring these trailing arguments, only overloads that can take this exact number of arguments are considered. If there are none, then a TypeError is thrown.

~~正しい個数の引数をとる,多重定義の集合が得られたなら、 ~JS値は左から右の順に変換される。 多重定義に対する制約の定義から、この時点で複数の多重定義の候補がある場合、引数~listの中で,最終的に選定される多重定義を判別する際の~~基準となる位置がある。 これが`判別引数~index$である。 ◎ Once we have a set of possible overloads with the right number of arguments, the ECMAScript values are converted from left to right. The nature of the restrictions on overloading means that if we have multiple possible overloads at this point, then there will be one position in the argument list that will be used to distinguish which overload we will finally select; this is the distinguishing argument index.

まず最初に,判別引数より左に位置する引数を変換する(これらの引数については、同じ~indexに位置する他の多重定義の引数と同じ型であることが要件にされている)。 次に、対応し得る~IDL型を決定するために,判別引数~indexの位置に渡された~JS値の型を検分する。 これにより、呼出されることになる多重定義の最終的な選定が可能になる。 渡された値が `undefined^v であって, かつ この位置に随意~引数を伴う多重定義がある場合、その多重定義が選定される。 このとき,渡された値の型に対する妥当な多重定義が無ければ、 `TypeError^t が投出される。 判別引数~indexに位置する値の検分は副作用を持たない。 多重定義~解決~algoを走らせることに因る唯一の副作用は、 ~JS値から~IDL値への変換-に因るものに限られる。 ◎ We first convert the arguments to the left of the distinguishing argument. (There is a requirement that an argument to the left of the distinguishing argument index has the same type as in the other overloads, at the same index.) Then we inspect the type of the ECMAScript value that is passed in at the distinguishing argument index to determine which IDL type it may correspond to. This allows us to select the final overload that will be invoked. If the value passed in is undefined and there is an overload with an optional argument at this position, then we will choose that overload. If there is no valid overload for the type of value passed in here, then we throw a TypeError. The inspection of the value at the distinguishing argument index does not have any side effects; the only side effects that come from running the overload resolution algorithm are those that come from converting the ECMAScript values to IDL values.

この段階で,利用する多重定義が決定されたことになる。 しかる後、判別引数に後続する残りの引数~値も左から右の順に変換する。 ここでも,前述の余分な引数は、無視される。 ◎ At this point, we have determined which overload to use. We now convert the remaining arguments, from the distinguishing argument onwards, again ignoring any additional arguments that were ignored due to being passed after the last possible argument.

随意~引数の~JS値からそれに等価な~IDL値へ変換する際には、 `undefined^v は,[ 随意~引数に`既定~値$が在ればそれに/ 無ければ`MISSING^に ]変換されることになる。 ◎ When converting an optional argument’s ECMAScript value to its equivalent IDL value, undefined will be converted into the optional argument’s default value, if it has one, or a special value “missing” otherwise.

しかしながら、`可変個~引数$に対応する随意~引数に対する `undefined^v は,`MISSING^とは見なされない。 この場合の `undefined^v 値は、必須の引数と同様に,`可変個~引数$の型に変換されることになる。 ◎ Optional arguments corresponding to a final, variadic argument do not treat undefined as a special “missing” value, however. The undefined value is converted to the type of variadic argument as would be done for a non-optional argument.

4.6. ~ifc

所与の~JS大域環境 %G にて`公開され$ている,どの`~ifc$ %I に対しても、 %I が次のいずれかの条件: ◎ For every interface that is exposed in a given ECMAScript global environment and:

  • `呼戻~ifc$である, かつ `定数$を伴って宣言されている ◎ is a callback interface that has constants declared on it, or
  • 非~呼戻`~ifc$である, かつ `NoInterfaceObject$x `拡張属性$を伴わずに宣言されている ◎ is a non-callback interface that is not declared with the [NoInterfaceObject] extended attribute,

を満たすならば、 %I に対応して,次の特徴を有する~propが %G の大域~obj上に存在し~MUST:

  • 名前は %I の`識別子$。
  • 値は `~ifc~obj@ と呼ばれる~obj — この~objの特徴については、下の `interface-object$sec にて述べる。
  • 属性 `TFT^desc を持つ。
◎ a corresponding property MUST exist on the ECMAScript environment's global object. The name of the property is the identifier of the interface, and its value is an object called the interface object. ◎ The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. The characteristics of an interface object are described in section 4.6.1 below.

加えて、 %G において `NamedConstructor$x 拡張属性を伴って`公開され$る,どの~ifcに対しても、次の特徴を有する~propが %G の大域~obj上に存在し~MUST:

  • 名前は `=^sym の直後に現れる `identifier$g
  • 値は、その~ifcを実装する~objの構築を可能にする, `有名~構築子@ と呼ばれる~obj — この構築子の特徴については、下の `named-constructors$sec にて述べる。
◎ In addition, for every [NamedConstructor] extended attribute on an exposed interface, a corresponding property MUST exist on the ECMAScript global object. The name of the property is the identifier that occurs directly after the “=”, and its value is an object called a named constructor, which allows construction of objects that implement the interface. The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. The characteristics of a named constructor are described in section 4.6.2 below.

4.6.X. 【この訳に特有の定義】

共通の記述を集約するため、この訳では次の非公式な定義を導入する(加えて、原文の定義を,より見通しのよい~~形に変形してもいる):

所与の~prop %p が ~ifc %A に対する `通例の場所に存在する@ とは,次を意味する:

  • %A が `Global$x / `PrimaryGlobal$x 注釈付きの~ifcでないならば、 %p は %A の`~ifc原型~obj$上に存在する。
  • また、ある `Global$x / `PrimaryGlobal$x 注釈付きの~ifc %G が存在して, %A が %G の`広義~帰結~ifc$であるならば、 %p は(前項に加えて,) %G を実装する単独の~obj上に存在する。
◎ If the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, then the property exists on the single object that implements the interface. ◎ Otherwise, if the interface is a consequential interface of a [Global]- or [PrimaryGlobal]-annotated interface, then the property exists on the single object that implements the [Global]- or [PrimaryGlobal]-annotated interface as well as on the consequential interface’s interface prototype object. ◎ Otherwise, the property exists solely on the interface’s interface prototype object.

4.6.1. ~ifc~obj

所与の非~呼戻`~ifc$に対応する~ifc~objは、`関数~obj$である。 それは、下の `es-constants$sec, `es-operations$sec にて述べるように,その~ifc上に定義される `定数$, `静的~演算$ のそれぞれに対応する~propを持つ。 ◎ The interface object for a given non-callback interface is a function object. It has properties that correspond to the constants and static operations defined on that interface, as described in sections 4.6.5 and 4.6.7 below.

非~呼戻~ifc %A に対応する~ifc~objの `Prototype^es 内的~propの値は、次のように決定される: ◎ The [[Prototype]] internal property of an interface object for a non-callback interface is determined as follows:

  1. %A が他の何らかの~ifc %B を継承する場合、 %B に対応する~ifc~obj。 ◎ If the interface inherits from some other interface, the value of [[Prototype]] is the interface object for that other interface.
  2. 他の場合、 `FunctionPrototype^ ( `ECMA-262$r 6.1.7.4 節)。 ◎ If the interface doesn't inherit from any other interface, the value of [[Prototype]] is %FunctionPrototype% ([ECMA-262], section 6.1.7.4).

非~呼戻~ifcに対応する~ifc~objは、次の特徴を有する~propを持た~MUST:

  • 名前は `prototype^l
  • 値は `~ifc原型~obj@ と呼ばれる~obj — この~objは、その~ifc上に定義される[ `正則~属性$, `正則~演算$ ]のそれぞれに対応する~propを持つ。 詳細は `interface-prototype-object$sec にて述べる。
  • 属性 `FFF^desc を持つ
◎ An interface object for a non-callback interface MUST have a property named “prototype” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is an object called the interface prototype object. This object has properties that correspond to the regular attributes and regular operations defined on the interface, and is described in more detail in section 4.6.3 below.

非~呼戻~ifcに対応する~ifc~objは `関数~obj$なので、 `typeof^c 演算子が その種の~ifc~objに適用されるときには, "`function^v" を返すようになることも意味する。 ◎ Since an interface object for a non-callback interface is a function object the typeof operator will return "function" when applied to such an interface object.

呼戻~ifcに対応する~ifc~objの `Prototype^es 内的~propは、 Object.prototype ~objで~MUST。 ◎ The internal [[Prototype]] property of an interface object for a callback interface MUST be the Object.prototype object.

呼戻~ifcに対応する~ifc~objが存在するのは,その`~ifc$上に`定数$が宣言されている場合に限られることに留意。 存在する場合、それらは関数~objではない。 ◎ Remember that interface objects for callback interfaces only exist if they have constants declared on them; when they do exist, they are not function objects.

4.6.1.1. ~ifc object `Call^es ~meth

`~ifc$が `Constructor$x `拡張属性$(構築子)を伴って宣言されている場合、 その`~ifc~obj$は,その~ifcを実装する~objを作成する関数として~callし得るものになる。 構築子を持たない~ifcが関数として~callされた場合は,例外が投出されることになる。 ◎ If the interface is declared with a [Constructor] extended attribute, then the interface object can be called as a function to create an object that implements that interface. Interfaces that do not have a constructor will throw an exception when called as a function.

`~ifc~obj$の `Call^es 内的~methは、 %arg0..%n−1 を構築子に渡された引数~値の~list, %I を対応する`~ifc$とするとき,次に従って挙動する: ◎ The internal [[Call]] method of the interface object behaves as follows, assuming arg0..n−1 is the list of argument values passed to the constructor, and I is the interface:

  1. ~IF %I は `Constructor$x `拡張属性$を伴って宣言されていない ~THEN ~THROW `TypeError^t ◎ If I was not declared with a [Constructor] extended attribute, then throw a TypeError.
  2. %id := %I の識別子 ◎ Let id be the identifier of interface I.
  3. %S :← %I 上の[ `識別子$ %id, 引数個数 %n ]の構築子からなる`有効~多重定義~集合$ ◎ Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count n.
  4. <%constructor, %values> := %S と %arg0..%n−1 を`多重定義~解決~algo$に渡した結果 ◎ Let <constructor, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.
  5. %R := %values を一連の引数~値として, %constructor の記述に挙げられている手続きを遂行した結果 ◎ Let R be the result of performing the actions listed in the description of constructor with values as the argument values.
  6. ~RET %R を型 %I の~JS`~ifc型$ 値に`toES^した結果 ◎ Return the result of converting R to an ECMAScript interface type value I.

`~ifc~obj$の `Call^es 内的~methが返す値は、~ifc %I を実装する~objで~MUST。 この~objは~ifc~objが属する~JS大域環境にも結付けられてい~MUST。 ◎ If the internal [[Call]] method of the interface object returns normally, then it MUST return an object that implements interface I. This object also MUST be associated with the ECMAScript global environment associated with the interface object.

呼戻でない~ifc %I に対応する~ifc~objは、次の特徴を有する~propを持た~MUST:

  • 名前は `length^l
  • 属性 `FFT^desc を持つ
  • 値は 下に与える手続きから決定される `Number^t 値
◎ Interface objects for non-callback interfaces MUST have a property named “length” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is a Number. If the [Constructor] extended attribute does not appear on the interface definition, then the value is 0. Otherwise, the value is determined as follows:
  1. ~IF %I の定義には `Constructor$x 拡張属性は現れない ~THEN ~RET 0 ◎ ↑
  2. %id := ~ifc %I の識別子 ◎ Let id be the identifier of interface I.
  3. %S :← `~ifc$ %I 上の[ `識別子$ %id, 引数個数 0 ]の構築子からなる`有効~多重定義~集合$ ◎ Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count 0.
  4. ~RET %S の中の~entryの引数~listの長さのうち,最小の長さ ◎ Return the length of the shortest argument list of the entries in S.

どの~ifc~objも、次の特徴を有する~propを持た~MUST:

  • 名前は `name^l
  • 値は 対応する~ifcの識別子
◎ All interface objects MUST have a property named “name” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is the identifier of the corresponding interface.
4.6.1.2. ~ifc object `HasInstance^es ~meth

どの~ifc~obj %A に対しても,その `HasInstance^es 内的~methは、 %V をその引数とするとき,次に従って挙動し~MUST: ◎ The internal [[HasInstance]] method of every interface object A MUST behave as follows, assuming V is the object argument passed to [[HasInstance]]:

  1. ~IF %V は ~objでない ~THEN ~RET `false^v ◎ If V is not an object, return false.
  2. %O := ~prop名 `prototype^l により, %A の `Get^es ~methを~callした結果 ◎ Let O be the result of calling the [[Get]] method of A with property name “prototype”.
  3. ~IF %O は ~objでない ~THEN ~THROW `TypeError^t ◎ If O is not an object, throw a TypeError exception.
  4. ~IF %V は[ %O を`~ifc原型~obj$に持つ`~ifc$ ]を実装する`~platform~obj$である ~THEN ~RET `true^v ◎ If V is a platform object that implements the interface for which O is the interface prototype object, return true.
  5. ~WHILE 無条件: ◎ Repeat:

    1. %V ← %V の `Prototype^es 内的~propの値 ◎ Set V to the value of the [[Prototype]] internal property of V.
    2. ~IF %V ~EQ `null^v ~THEN ~RET `false^v ◎ If V is null, return false.
    3. ~IF %O と %V が同じ~objを指している ~THEN ~RET `true^v ◎ If O and V refer to the same object, return true.

4.6.2. 有名~構築子

`有名~構築子$は、`識別子$( %id とする)を伴う1個~以上の `NamedConstructor$x `拡張属性$により 存在することになる,`関数~obj$である。 それは、その拡張属性が現れる`~ifc$( %I とする)を実装する~objの構築を可能にする, `Call^es 内的~prop を持た~MUST。 それは、 %arg0..%n−1 を構築子に渡された引数~値の~listとするとき,次に従って挙動する: ◎ A named constructor that exists due to one or more [NamedConstructor] extended attributes with a given identifier is a function object. It MUST have a [[Call]] internal property, which allows construction of objects that implement the interface on which the [NamedConstructor] extended attributes appear. It behaves as follows, assuming arg0..n−1 is the list of argument values passed to the constructor, id is the identifier of the constructor specified in the extended attribute named argument list, and I is the interface on which the [NamedConstructor] extended attribute appears:

`有名~構築子$の `Call^es 内的~methが返す値は、~ifc %I を実装する~objで~MUST。 この~objは、その`有名~構築子$が属する~JS大域環境に属してい~MUST。 ◎ If the internal [[Call]] method of the named constructor returns normally, then it MUST return an object that implements interface I. This object also MUST be associated with the ECMAScript global environment associated with the named constructor.

有名~構築子は、次の特徴を有する~propを持た~MUST:

  • 名前は `length^l
  • 値は、次に与える手続きから決定される `Number^t
◎ A named constructor MUST have a property named “length” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is a Number determined as follows:

有名~構築子は、次の特徴を有する~propを持た~MUST:

  • 名前は `name^l
  • 値は 構築子に利用されている識別子。
◎ A named constructor MUST have a property named “name” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is the identifier used for the named constructor.

有名~構築子は、次の特徴を有する~propも持た~MUST:

  • 値は `NamedConstructor$x `拡張属性$が現れた`~ifc$に対応する`~ifc原型~obj$。
◎ A named constructor MUST also have a property named “prototype” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is the interface prototype object for the interface on which the [NamedConstructor] extended attribute appears.

4.6.3. ~ifc原型~obj

定義されたどの非~呼戻`~ifc$に対しても、その~ifcが `NoInterfaceObject$x `拡張属性$を伴って宣言されたかどうかに関わらず,対応する`~ifc原型~obj$が存在し~MUST。 個々の~ifcに対し,その~ifc原型~objは、その~ifc上に定義される[ `正則~属性$, `正則~演算$ ]のそれぞれに対応する~propを持つ。 これらの~propについての詳細は `es-attributes$sec, `es-operations$sec にて述べる。 ◎ There MUST exist an interface prototype object for every non-callback interface defined, regardless of whether the interface was declared with the [NoInterfaceObject] extended attribute. The interface prototype object for a particular interface has properties that correspond to the regular attributes and regular operations defined on that interface. These properties are described in more detail in sections 4.6.6 and 4.6.7 below.

`~ifc~obj$と同様に,~ifc原型~objも その~ifc上に定義される`定数$に対応する~propを持つ(下の `es-constants$sec にて述べる)。 ◎ As with the interface object, the interface prototype object also has properties that correspond to the constants defined on that interface, described in section 4.6.5 below.

その~ifc上に `NoInterfaceObject$x 拡張属性が指定されていない場合、その~ifc原型~objは,次の特徴を有する~propを持た~MUST:

  • 名前は `constructor^l
  • 値は その~ifcに対応する~ifc~objへの参照
◎ If the [NoInterfaceObject] extended attribute was not specified on the interface, then the interface prototype object MUST also have a property named “constructor” with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } whose value is a reference to the interface object for the interface.

所与の~ifc %A に対応する`~ifc原型~obj$は、次に与える値をとる, `Prototype^es 内的~propを持た~MUST: ◎ The interface prototype object for a given interface A MUST have an internal [[Prototype]] property whose value is returned from the following steps:

  1. %A が `Global$x / `PrimaryGlobal$x `拡張属性$を伴って宣言されていて, かつ `有名~propを~supportする$ならば、下の `named-properties-object$sec にて定義される, %A に対応する`有名~prop~obj$ ◎ If A is declared with the [Global] or [PrimaryGlobal] extended attribute, and A supports named properties, then return the named properties object for A, as defined in section 4.6.4 below.
  2. 他の場合: ◎ Otherwise,

    1. %A が別の~ifc %B を継承するように宣言されているならば、 %B に対応する`~ifc原型~obj$ ◎ If A is declared to inherit from another interface, then return the interface prototype object for the inherited interface.
    2. 他の場合, %A が `LegacyArrayClass$x 拡張属性を伴って宣言されているならば、 `ArrayPrototype^ ( `ECMA-262$r 6.1.7.4 節) ◎ Otherwise, if A is declared with the [LegacyArrayClass] extended attribute, then return %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
    3. 他の場合、 `ObjectPrototype^ ( `ECMA-262$r 6.1.7.4 節) ◎ Otherwise, return %ObjectPrototype% ([ECMA-262], section 6.1.7.4).

`NoInterfaceObject$x `拡張属性$を伴って定義された`~ifc$に対応する`~ifc原型~obj$は、その~ifcが非`追補~ifc$ として利用されているならば~access可能になる。 例えば、次の~IDLでは: ◎ The interface prototype object of an interface that is defined with the [NoInterfaceObject] extended attribute will be accessible if the interface is used as a non-supplemental interface. For example, with the following IDL:

[NoInterfaceObject]
interface Foo {
};

partial interface Window {
  attribute Foo foo;
};

`~ifc~obj$を通して ~ifc原型~objに~accessすることはできない( `window.Foo^c として存在しないので)。 しかしながら、 `Foo^T の~instanceは,その `Prototype^es 内的~prop値の取得 — この例では, `Object.getPrototypeOf(window.foo)^c — により,~ifc原型~objを公開し得る。 ◎ it is not possible to access the interface prototype object through the interface object (since it does not exist as window.Foo). However, an instance of Foo can expose the interface prototype object by gettings its internal [[Prototype]] property value – Object.getPrototypeOf(window.foo) in this example.

~ifcがもっぱら`追補~ifc$として利用されている場合、その~ifc原型~objを `Prototype^es 内的~propの値にとる~objは存在しないので、~ifc原型~objに~accessする仕方はないことになる。 そのような場合、この~objが存在しないことは,受容し得る最適化になる。 ◎ If the interface is used solely as a supplemental interface, then there will be no way to access its interface prototype object, since no object will have the interface prototype object as its internal [[Prototype]] property value. In such cases, it is an acceptable optimization for this object not to exist.

~ifcのいずれかの`広義~帰結~ifc$が,[ `Unscopable$x 拡張属性を伴って宣言された`~ifc~mb$ ]を持つ場合(そのような~mbからなる集合を %M とする)、その~ifc原型~obj上には,次の特徴を有する~propが存在し~MUST:

  • 名前は `unscopables_symbol^ ~symbol
  • 値は 次の手続きで作成される~obj
◎ If the interface or any of its consequential interfaces has any interface member declared with the [Unscopable] extended attribute, then there MUST be a property on the interface prototype object whose name is the @@unscopables symbol and whose value is an object created as follows:
  1. %object := 式 `({})^c により作成されるものと同じ,新たな~obj ◎ Let object be a new object created as if by the expression ({}).
  2. %M 内の ~EACH ( %m ) に対し:

    1. `CreateDataProperty$A( %object, %m の`識別子$, `true^v ) を~callする
    ◎ For each of the aforementioned interface members declared with the [Unscopable] extended attribute, call CreateDataProperty(object, the identifier of the interface member, true).
  3. ~RET %object ◎ Return object.

`~ifc原型~obj$の `~class文字列$は[ `~ifc$の`識別子$, 文字列 `Prototype^l ]の連結である。 ◎ The class string of an interface prototype object is the concatenation of the interface’s identifier and the string “Prototype”.

4.6.4. 有名~prop~obj

`Global$x / `PrimaryGlobal$x `拡張属性$を伴って宣言されていて, かつ `有名~propを~supportする$ どの`~ifc$に対しても、その~ifcに対応する `有名~prop~obj@ と呼ばれる~objが存在し~MUST。 ◎ For every interface declared with the [Global] or [PrimaryGlobal] extended attribute that supports named properties, there MUST exist an object known as the named properties object for that interface.

所与の~ifc %A に対応する`有名~prop~obj$は、次に従って決定される値をとる, `Prototype^es 内的~propを持た~MUST: ◎ The named properties object for a given interface A MUST have an internal [[Prototype]] property whose value is returned from the following steps:

`有名~prop~obj$の `~class文字列$は[ `~ifc$の`識別子$, 文字列 `Properties^l ]の連結である。 ◎ The class string of a named properties object is the concatenation of the interface’s identifier and the string “Properties”.

4.6.4.1. 有名~prop~obj `GetOwnProperty^es ~meth

どの`有名~prop~obj$についても,その `GetOwnProperty^es 内的~methは[ ~obj %O, ~prop名 %P ]を伴って~callされたときには,次に従って挙動し~MUST: ◎ The internal [[GetOwnProperty]] method of every named properties object MUST behave as follows when called with object O and property name P:

  1. %A := `有名~prop~obj$ %O に対する`~ifc$ ◎ Let A be the interface for the named properties object O.
  2. %object := %O が属する~JS大域環境に属する, %A を実装する~~唯一の~obj ◎ Let object be the sole object from O’s ECMAScript global environment that implements A.

    例えば,`~ifc$が HTML5 で定義される `Window^T ~ifc ( `HTML5$r, 5.2 節) であるならば、この大域環境の window ~objが~~唯一の~objになる。 ◎ For example, if the interface is the Window interface as defined in HTML5 ([HTML5], section 5.2), then the sole object will be this global environment’s window object.

  3. ~IF[ ( ~prop名 %P, ~obj %object ) を~~入力に,`有名~propの可視性判定~algo$を走らせた結果 ~EQ true ⇒ ◎ If the result of running the named property visibility algorithm with property name P and object object is true, then:

    1. %operation := `有名~prop取得子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the named property getter.
    2. %value :← 未初期化の変数 ◎ Let value be an uninitialized variable.
    3. ~IF %operation は `識別子$なしに定義されている ~THEN %value ← [ 名前 %P に対し,~ifcの記述に挙げられている `有名~propの値を決定する$ 手続きを遂行した結果 ] ◎ If operation was defined without an identifier, then set value to the result of performing the steps listed in the interface description to determine the value of a named property with P as the name.
    4. ~ELSE ~THEN %value ← [ ( %P ) を引数に, %operation の記述に挙げられている手続きを遂行した結果 ] ◎ Otherwise, operation was defined with an identifier. Set value to the result of performing the steps listed in the description of operation with P as the only argument value.
    5. ~RET 次の様な新たな`~pdesc$( `ECMA-262$r 6.2.4 節): ◎ Let desc be a newly created Property Descriptor ([ECMA-262], section 6.2.4) with no fields.

         `TET-V^desc — ここで:
      • %V := %value を~JS値に`toES^した結果
      • %E := [ %A が実装するある~ifcに, `LegacyUnenumerableNamedProperties$x `拡張属性$が伴われているならば `false^v / ~ELSE_ `true^v ]
      ◎ Set desc.[[Value]] to the result of converting value to an ECMAScript value. ◎ If A implements an interface with the [LegacyUnenumerableNamedProperties] extended attribute, then set desc.[[Enumerable]] to false, otherwise set it to true. ◎ Set desc.[[Writable]] to true and desc.[[Configurable]] to true. ◎ Return desc.
  4. ~RET `OrdinaryGetOwnProperty$A( %O, %P ) ◎ Return OrdinaryGetOwnProperty(O, P).
4.6.4.2. 有名~prop~obj `DefineOwnProperty^es ~meth

`有名~prop~obj$ %O の `DefineOwnProperty^es 内的~methは,[ ~prop~key %P, `~pdesc$( `ECMA-262$r 6.2.4 節) %Desc ]を伴って~callされたときは、次の手続きに従わ~MUST: ◎ When the internal [[DefineOwnProperty]] method of a named properties object O is called with property key P and Property Descriptor ([ECMA-262], section 6.2.4) Desc, the following steps MUST be taken:

  1. ~RET `false^v ◎ Return false.
4.6.4.3. 有名~prop~obj `Delete^es ~meth

どの`有名~prop~obj$についても,その `Delete^es 内的~methは、[ ~obj %O, ~prop名 %P ]を伴って~callされたときには,次に従って挙動し~MUST。 ◎ The internal [[Delete]] method of every named properties object MUST behave as follows when called with object O and property name P.

  1. ~RET `false^v ◎ Return false.

4.6.5. 定数

`~ifc$上で定義され, かつ`公開され$ている どの`定数$に対しても、次の特徴を有する,対応する~propが存在し~MUST: ◎ For each exposed constant defined on an interface A, there MUST be a corresponding property. The property has the following characteristics:

  • 名前は 定数の`識別子$。 ◎ The name of the property is the identifier of the constant.
  • ~propは ~ifcに対する`通例の場所に存在する$。 ◎ The location of the property is determined as follows: • If the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, then the property exists on the single object that implements the interface. • Otherwise, if the interface is a consequential interface of a [Global]- or [PrimaryGlobal]-annotated interface, then the property exists on the single object that implements the [Global]- or [PrimaryGlobal]-annotated interface as well as on the consequential interface’s interface prototype object. • Otherwise, the property exists solely on the interface’s interface prototype object.

  • 値は 定数の~IDL値を~JS値に`toES^した結果。 ◎ The value of the property is that which is obtained by converting the constant’s IDL value to an ECMAScript value.
  • 属性 `FTF^desc を持つ。 ◎ The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

加えて、`~ifc原型~obj$が在る場合は、同じ特徴を有する~propが,その~obj上にも存在し~MUST。 ◎ In addition, a property with the same characteristics MUST exist on the interface object, if that object exists.

4.6.6. 属性

`~ifc$において,その いずれかの`広義~帰結~ifc$により `公開され$ている各 `属性$(以下, `属性^ と記す)に対しては、次の特徴を有する,対応する~propが存在し~MUST: ◎ For each exposed attribute of the interface, whether it was declared on the interface itself or one of its consequential interfaces, there MUST exist a corresponding property. The characteristics of this property are as follows:

  • 名前は `属性^ の`識別子$ ◎ The name of the property is the identifier of the attribute.
  • ~propの所在は、次のように決定される: ◎ The location of the property is determined as follows:

    • `属性^ が`静的~属性$である場合、対応する単独の~propが, ~ifcに対する`~ifc~obj$上に存在する。 ◎ If the attribute is a static attribute, then there is a single corresponding property and it exists on the interface’s interface object.
    • 他の場合, `属性^ が~ifc上で`偽装不可$であるならば、~propは, ~ifcを実装するどの~obj上にも存在する。 ◎ Otherwise, if the attribute is unforgeable on the interface or if the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, then the property exists on every object that implements the interface. ◎ ↓
    • 他の場合、~propは ~ifcに対する`通例の場所に存在する$。 ◎ ↑ ◎ Otherwise, if the interface is a consequential interface of a [Global]- or [PrimaryGlobal]-annotated interface, then the property exists on the single object that implements the [Global]- or [PrimaryGlobal]-annotated interface as well as on the consequential interface’s interface prototype object. ◎ Otherwise, the property exists solely on the interface’s interface prototype object.
  • 属性 { [[Get]]: %G, [[Set]]: %S, [[Enumerable]]: `true^v, [[Configurable]]: %configurable } を持つ。ここで: ◎ The property has attributes { [[Get]]: G, [[Set]]: S, [[Enumerable]]: true, [[Configurable]]: configurable }, where:

    • %configurable は[ `属性^ が `Unforgeable$x 拡張属性を伴って宣言されているならば `false^v / ~ELSE_ `true^v ] ◎ configurable is false if the attribute was declared with the [Unforgeable] extended attribute and true otherwise;
    • %G は下で定義される`属性~取得子$ ◎ G is the attribute getter, defined below; and
    • %S は下で定義される`属性~設定子$ ◎ S is the attribute setter, also defined below.

`属性~取得子@ は、被呼出時の挙動が次で与えられる, `Function^t ~obj %F である: ◎ The attribute getter is a Function object whose behavior when invoked is as follows:

  1. %idlValue :← ~IDL値をとる未初期化の変数 ◎ Let idlValue be an IDL value determined as follows.
  2. ~IF `属性^ は `正則~属性$である ⇒ ◎ If the attribute is a regular attribute, then:

    1. %I := この( `属性^ に対応している)~propが`~ifc原型~obj$上に現れるような,`~ifc$ ◎ Let I be the interface whose interface prototype object this property corresponding to the attribute appears on.

      このことは、 `属性^ が`~implements文$により~ifc上にて可用になったとしても、 %I は `属性^ が元々宣言された方ではなく,~implements文の左側の~ifcであることを意味する。 ◎ This means that even if an implements statement was used to make an attribute available on the interface, I is the interface on the left hand side of the implements statement, and not the one that the attribute was originally declared on.

    2. %O := `this^v 値 ◎ Let O be the this value.
    3. ~IF %O は `~platform~obj$である ~THEN ( %O, %F, `属性^ の`識別子$, `取得子^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function that implements the attribute getter, • the identifier of the attribute, and • the type “getter”.
    4. ~IF %O は %I を実装する`~platform~obj$でない ⇒ ◎ If O is not a platform object that implements I, then:

      1. ~IF `属性^ が `LenientThis$x `拡張属性$を伴って指定されている ~THEN ~RET `undefined^v ◎ If the attribute was specified with the [LenientThis] extended attribute, then return undefined.
      2. ~ELSE ~THEN ~THROW `TypeError^t ◎ Otherwise, throw a TypeError.
    5. %idlValue ← %O を~objとして、[ `属性^,あるいは[ `属性^ がその`取得子を継承-$するように宣言されている場合は,継承された属性 ]]の記述に挙げられている,取得~時に生じる手続きを遂行した結果 ◎ Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting (or those listed in the description of the inherited attribute, if this attribute is declared to inherit its getter), with O as the object.
  3. ~ELSE (すなわち `属性^ は`静的~属性$) ~THEN %idlValue ← `属性^ の記述に挙げられている,取得~時に生じる手続きを遂行した結果 ◎ Otherwise, the attribute is a static attribute. Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting.
  4. ~RET %idlValue を~JS値に`toES^した結果 ◎ Let V be the result of converting idlValue to an ECMAScript value. ◎ Return V.

この `Function^t ~objの `length^l ~propの値は、 `Number^t 値 `0^v である。 ◎ The value of the Function object’s “length” property is the Number value 0.

この `Function^t ~objの `name^l ~propの値は、[ `get^l , 属性の識別子 ]を連結して得られる `String^t 値である。 ◎ The value of the Function object’s “name” property is a String whose value is the concatenation of “get ” and the identifier of the attribute.

`属性~設定子@ は、 `属性^ の宣言に `readonly^c が伴われていて, かつ[ `LenientThis$x, `PutForwards$x, `Replaceable$x ]のいずれの`拡張属性$も伴われていない場合、 `undefined^v である。 他の場合、被呼出時の挙動が次で与えられる, `Function^t ~obj %F である: ◎ The attribute setter is undefined if the attribute is declared readonly and does not have a [LenientThis], [PutForwards] or [Replaceable] extended attribute declared on it. Otherwise, it is a Function object whose behavior when invoked is as follows:

  1. ~IF %F に引数が渡されていない ~THEN ~THROW `TypeError^t ◎ If no arguments were passed to the Function, then throw a TypeError.
  2. %V := %F に渡された第一~引数の値 ◎ Let V be the value of the first argument passed to the Function.
    1. ~IF %O は `~platform~obj$である ~THEN ( %O, %F, 属性の`識別子$, `設定子^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function that implements the attribute setter, • the identifier of the attribute, and • the type “setter”.
    2. %validThis := [ %O が %I を実装する`~platform~obj$ならば `true^v / ~ELSE_ `false^v ] ◎ Let validThis be true if O is a platform object that implements I, or false otherwise.
    3. ~IF[ %validThis ~EQ `false^v ]~AND[ `属性^ は `LenientThis$x `拡張属性$を伴って指定されていない ] ~THEN ~THROW `TypeError^t ◎ If validThis is false and the attribute was not specified with the [LenientThis] extended attribute, then throw a TypeError.
    4. ~IF `属性^ は `Replaceable$x 拡張属性を伴って宣言されている ⇒ ◎ If the attribute is declared with a [Replaceable] extended attribute, then:

      1. %P := `属性^ の識別子 ◎ Let P be the identifier of the attribute.
      2. `CreateDataProperty$A( %O, %P, %V ) を~callする ◎ Call CreateDataProperty(O, P, V).
      3. ~RET `undefined^v ◎ Return undefined.
    5. ~IF %validThis ~EQ `false^v ~THEN ~RET `undefined^v ◎ If validThis is false, then return undefined.
    6. ~IF `属性^ は `LenientSetter$x 拡張属性を伴って宣言されている: ~THEN ~RET `undefined^v ◎ If the attribute is declared with a [LenientSetter] extended attribute, then return undefined.
    7. ~IF `属性^ は `PutForwards$x 拡張属性を伴って宣言されている: ◎ If the attribute is declared with a [PutForwards] extended attribute, then:

      1. %Q := `属性^ の識別子を~prop名に利用して, %O 上の `Get^es ~methを~callした結果 ◎ Let Q be the result of calling the [[Get]] method on O using the identifier of the attribute as the property name.
      2. ~IF %Q は ~objでない ~THEN ~THROW `TypeError^t ◎ If Q is not an object, then throw a TypeError.
      3. %A := `PutForwards$x 拡張属性により識別される属性 ◎ Let A be the attribute identified by the [PutForwards] extended attribute.
      4. %A の識別子を~prop名に, %V を値に利用して, %Q 上の `Put^es ~methを~callする ◎ Call the [[Put]] method on Q using the identifier of A as the property name and V as the value.
      5. ~RET `undefined^v ◎ Return undefined.
  3. %idlValue := 次で決定される~IDL値: ◎ Let idlValue be an IDL value determined as follows:

    • ~IF `属性^ の型は `列挙$である ⇒ ◎ If the type of the attribute is an enumeration, then:

      1. %S := `ToString$A( %V ) ◎ Let S be the result of calling ToString(V).
      2. ~IF %S は `列挙~値$のいずれでもない ~THEN ~RET `undefined^v ◎ If S is not one of the enumeration’s values, then return undefined.
      3. %idlValue は %S に等しい列挙~値 ◎ The value of idlValue is the enumeration value equal to S.
    • ~ELSE ~THEN %idlValue は %V を~IDL値に`toIDL^した結果 ◎ Otherwise, the type of the attribute is not an enumeration. The value of idlValue is the result of converting V to an IDL value.
  4. %idlValue を値として, 加えて[ `属性^ が`正則~属性$であるならば %O を~objとして ], `属性^ の設定が生じる際の記述に挙げられている手続きを遂行する ◎ If the attribute is a regular attribute, then perform the actions listed in the description of the attribute that occur when setting, with O as the object and idlValue as the value. ◎ Otherwise, the attribute is a static attribute. Perform the actions listed in the description of the attribute that occur when setting with idlValue as the value.
  5. ~RET `undefined^v ◎ Return undefined.

この `Function^t ~objの `length^l ~propの値は、 `Number^t 値 `1^v である。 ◎ The value of the Function object’s “length” property is the Number value 1.

この `Function^t ~objの `name^l ~propの値は、[ `set^l , 属性の識別子 ]を連結して得られる `String^t 値である。 ◎ The value of the Function object’s “name” property is a String whose value is the concatenation of “set ” and the identifier of the attribute.

1個の~IDL属性に対応する~propは【~~通常は】1個に限られるが、~accessor~prop[ 取得子/設定子 ]には,[[ その~IDL属性に対応する~prop ]が~accessされた ]~objを指す `this^v 値が渡されるので、それらの~propは,~instance特有の~dataを公開できる。 ◎ Although there is only a single property for an IDL attribute, since accessor property getters and setters are passed a this value for the object on which property corresponding to the IDL attribute is accessed, they are able to expose instance-specific data.

`読専$`属性$に対応する~propへの代入を試みた結果は、それを行う~scriptが~strict-modeであるかどうかに依存して異なる挙動になることに注意。 ~strict-modeの場合、その種の代入により `TypeError^t が投出されることになる。 ~strict-modeでない場合、代入の試みは無視されることになる。 ◎ Note that attempting to assign to a property corresponding to a read only attribute results in different behavior depending on whether the script doing so is in strict mode. When in strict mode, such an assignment will result in a TypeError being thrown. When not in strict mode, the assignment attempt will be ignored.

4.6.7. 演算

`~ifc$上に定義され, かつ`公開され$ている`演算$の各~一意な`識別子$ごとに、次の特徴を有する,対応する~propが存在し~MUST — ただし、[ その`識別子$, 引数個数 0 ]の`演算$からなる`有効~多重定義~集合$が空~集合である場合 【 要するに演算が識別子を伴わない場合? 】 は除く(以下,当の演算を `演算^ と記す): ◎ For each unique identifier of an exposed operation defined on the interface, there MUST exist a corresponding property, unless the effective overload set for that identifier and operation and with an argument count of 0 has no entries. ◎ The characteristics of this property are as follows:

  • 名前は `演算^ の`識別子$ ◎ The name of the property is the identifier.
    • `演算^ が`静的~演算$である場合、~propは ~ifcに対する`~ifc~obj$上に存在する。 ◎ If the operation is static, then the property exists on the interface object.
    • 他の場合, `演算^ が~ifc上で`偽装不可$であるならば、~propは,~ifcを実装するどの~obj上にも存在する。 ◎ Otherwise, if the operation is unforgeable on the interface or if the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, then the property exists on every object that implements the interface. ◎ ↓
  • 属性 `BTB^desc を持つ。 ここで %B は[ `演算^ が~ifc上で`偽装不可$である場合は `false^v / ~ELSE_ `true^v ]である。 ◎ The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, where B is false if the operation is unforgeable on the interface, and true otherwise.
  • 値は 下に与える `Function^t ~obj %F 。 ◎ ↓

`演算^ を実装する %F は、[ %id := `識別子$, %arg0..%n−1 := 関数に渡す引数~値の~list ]を渡したときに,次に従って挙動し~MUST: ◎ The value of the property is a Function object whose behavior is as follows, assuming id is the identifier, arg0..n−1 is the list of argument values passed to the function:

  1. ~TRY: ◎ Try running the following steps:

    1. %I := この( `演算^ に対応している)~propが`~ifc原型~obj$上(静的~演算の場合は`~ifc~obj$上)に現れるような,`~ifc$ ◎ Let I be the interface whose interface prototype object (or interface object, for a static operation) this property corresponding to the operation appears on.

      このことは、 `演算^ が`~implements文$により~ifc上にて可用になったとしても、 %I は `演算^ が元々宣言された方ではなく,~implements文の左側の~ifcであることを意味する。 ◎ This means that even if an implements statement was used to make an operation available on the interface, I is the interface on the left hand side of the implements statement, and not the one that the operation was originally declared on.

    2. %O := 次で定まる値: ◎ Let O be a value determined as follows:

      1. ~IF `演算^ は 静的~演算である ~THEN %O ← `null^v ◎ If the operation is a static operation, then O is null.
      2. ~ELIF[ `演算^ が現れる`~ifc$は `ImplicitThis$x `拡張属性$を持つ ]~AND[ `this^v 値 ~IN { `null^v, `undefined^v } ] ~THEN %O ← `Function^t ~objに結付けられている~JS大域~obj ◎ Otherwise, if the interface on which the operation appears has an [ImplicitThis] extended attribute, and the this value is null or undefined, then O is the ECMAScript global object associated with the Function object.
      3. ~ELIF `this^v 値 ~NEQ `null^v ~THEN %O ← その `this^v 値 ◎ Otherwise, if the this value is not null, then O is the this value.
      4. ~ELSE ~THEN ~THROW `TypeError^t ◎ Otherwise, throw a TypeError.
    3. ~IF %O は `~platform~obj$である ~THEN ( %O, %F, `演算^ の`識別子$, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function that implements the operation, • the identifier of the operation, and • the type “method”.
    4. ~IF[ %O ~NEQ `null^v ]~AND[ %O は ~ifc %I を実装する`~platform~obj$でない ] ~THEN ~THROW `TypeError^t ◎ If O is not null and is also not a platform object that implements interface I, throw a TypeError.
    5. %S := `~ifc$ %I 上の,[ `識別子$ %id, 引数個数 %n ]の[ `演算^ が正則~演算である場合は`正則~演算$ / 静的~演算である場合は`静的~演算$ ]からなる`有効~多重定義~集合$ ◎ Initialize S to the effective overload set for regular operations (if the operation is a regular operation) or for static operations (if the operation is a static operation) with identifier id on interface I and with argument count n.
    6. <%operation, %values> := %S と %arg0..%n−1 を`多重定義~解決~algo$に渡した結果 ◎ Let <operation, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.
    7. %R := ( %values ) を引数に, %operation の記述に挙げられている手続きを( `演算^ が静的~演算でないならば %O 上で)遂行した結果 ◎ Let R be the result of performing (on O, if the operation is not a static operation) the actions listed in the description of operation with values as the argument values.
    8. ~RET %R を[ `演算^ の返値に宣言された型 ]の~JS値に`toES^した結果 ◎ Return the result of converting R to an ECMAScript value of the type op is declared to return.
  2. ~CATCH: ◎ And then, if an exception was thrown:

    1. ~IF `演算^ の`返値型$は `~promise型$である ~THEN ~RET 次を渡して[ `Promise^.reject の初期~値 ]を~callした結果:

      • `this^v ~obj: `Promise^
      • 引数: ( `投出された例外$ )
      ◎ If the operation has a return type that is a promise type, then: • Let reject be the initial value of %Promise%.reject. • Return the result of calling reject with %Promise% as the this object and the exception as the single argument value.
    2. ~THROW `投出された例外$ ◎ Otherwise, end these steps and allow the exception to propagate.

この `Function^t object の `length^l ~propの値は、次に従って決定される `Number^t である: ◎ The value of the Function object’s “length” property is a Number determined as follows:

  1. %S := `~ifc$ %I 上の,[ `識別子$ %id, 引数個数 0 ]の[ `演算^ が正則~演算である場合は`正則~演算$ / 静的~演算である場合は`静的~演算$ ]からなる`有効~多重定義~集合$ ◎ Let S be the effective overload set for regular operations (if the operation is a regular operation) or for static operations (if the operation is a static operation) with identifier id on interface I and with argument count 0.

この `Function^t ~objの `name^l ~propの値は、演算の識別子による `String^t 値である。 ◎ The value of the Function object’s “name” property is a String whose value is the identifier of the operation.

4.6.7.1. 文字列化子

`~ifc$が`公開され$ている`文字列化子$(以下 `文字列化子^ と記す)を持つ場合、次の特徴を有する~propが存在し~MUST: ◎ If the interface has an exposed stringifier, then there MUST exist a property with the following characteristics:

  • 名前は `toString^l ◎ The name of the property is “toString”.
  • ~propの所在は: `文字列化子^ が~ifc上で`偽装不可$であるか, または ~ifcが `Global$x / `PrimaryGlobal$x 拡張属性を伴って宣言されているならば、~ifcを実装するどの~obj上にも存在する。 他の場合、~ifcの`~ifc原型~obj$上に存在する。 ◎ If the stringifier is unforgeable on the interface or if the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, then the property exists on every object that implements the interface. Otherwise, the property exists on the interface prototype object.
  • 属性 `BTB^desc を持つ。 ここで %B は[ `文字列化子^ が~ifc上で`偽装不可$である場合は `false^v / ~ELSE_ `true^v ]である。 ◎ The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, where B is false if the stringifier is unforgeable on the interface, and true otherwise.
  • 値は 下に与える `Function^t ~obj %F 。 ◎ ↓

~prop値 %F は、被呼出時には次に従って挙動し~MUST: ◎ The value of the property is a Function object, which behaves as follows:

  1. %O := `this^v 値~上で `ToObject$A を~callした結果 ◎ Let O be the result of calling ToObject on the this value.
  2. ~IF %O は `~platform~obj$である ~THEN ( %O, %F, `文字列化子^ の`識別子$, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function that implements the stringifier, • the identifier of the stringifier, and • the type “method”.
  3. ~IF %O は[ `文字列化子^ を宣言する~ifcを実装する~obj ]でない ~THEN ~THROW `TypeError^t ◎ If O is not an object that implements the interface on which the stringifier was declared, then throw a TypeError.
  4. %V :← 未初期化の変数 ◎ Let V be an uninitialized variable.
  5. `stringifier^c が指定されている場所に応じて: ◎ Depending on where stringifier was specified:

    `属性$上 ◎ on an attribute
    %V ← %O を~objとして、[ その属性, あるいは[ その属性がその`取得子を継承-$するように宣言されている場合は,継承された属性 ]]の記述に挙げられている,取得~時に生じる手続きを遂行した結果 ◎ Set V to the result of performing the actions listed in the description of the attribute that occur when getting (or those listed in the description of the inherited attribute, if this attribute is declared to inherit its getter), with O as the object.
    識別子を伴う`演算$上 ◎ on an operation with an identifier
    %V ← %O を `this^v 値として, 引数は渡さずに、その演算の記述に挙げられている手続きを遂行した結果 ◎ Set V to the result of performing the actions listed in the description of the operation, using O as the this value and passing no arguments.
    識別子を伴わない`演算$上 ◎ on an operation with no identifier
    %V ← ~ifcの`文字列化の挙動$を遂行した結果 ◎ Set V to the result of performing the stringification behavior of the interface.
  6. ~RET %V を `String^t 値に`toES^した結果 ◎ Return the result of converting V to a String value.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `toString^l である。 ◎ The value of the Function object’s “name” property is the String value “toString”.

4.6.7.2. 直列化子

`公開され$ている`直列化子$(以下 `直列化子^ と記す)を持つ`~ifc$に対しては、次の特徴を有する~propが存在し~MUST:

  • 名前は `toJSON^l
  • 属性 `TTT^desc を持つ
◎ If the interface has an exposed serializer, then a property MUST exist whose name is “toJSON”, with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a Function object.

~prop値 %F は、被呼出時には次に従って挙動し~MUST: ◎ The property’s Function object, when invoked, MUST behave as follows:

  1. ~IF %O は `~platform~obj$である ~THEN ( %O, %F, `直列化子^の`識別子$, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function that implements the serializer, • the identifier of the serializer, and • the type “method”.
  2. ~IF %O は[ `直列化子^ を宣言する~ifc ]を実装する~objでない ~THEN ~THROW `TypeError^t ◎ If O is not an object that implements the interface on which the serializer was declared, then throw a TypeError.
  3. `直列化子^ の `serializer^c の指定のされ方に応じて: ◎ Depending on how serializer was specified:

    識別子を伴う`演算$上に指定されたものである場合 ◎ on an operation with an identifier
    1. ~RET %O を `this^v 値に利用して, 引数を渡さずに,演算の記述に挙げられている手続きを遂行した結果 ◎ Return the result of performing the actions listed in the description of the operation, using O as the this value and passing no arguments.
    ~keywordとして指定されたものである場合 — `直列化~pattern$の有無に関わらず ◎ as a keyword, either with or without a serialization pattern
    1. %S := ~obj %O に対する~ifcの`直列化-時の挙動$を呼出した結果の`直列化形の値$ ◎ Let S be the serialized value that is the result of invoking the serialization behavior of the interface for object O.
    2. ~RET %S を`直列化値toES^した結果 ◎ Return the result of converting S to an ECMAScript value.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `toJSON^l である。 ◎ The value of the Function object’s “name” property is the String value “toJSON”.

`直列化形の値から~JS値に変換-@ する手続きは,次で定義される: ◎ The following steps define how to convert a serialized value to an ECMAScript value:

  1. %S := `直列化形の値$ ◎ Let S be the serialized value.
  2. %S の型に応じて: ◎ Depending on the type of S:

    ~map◎a map
    1. %O := 式 `({})^c により作成されるものと同じ,新たな~obj ◎ Let O be a new object created as if by the expression ({}).
    2. ~FOR %S 内の~EACH ( ~entry ) に対し,それらが~mapに追加された順に: ◎ For each entry in S, in the order they were added to the map:

      1. %V := ~entryの~valueを`直列化値toES^した結果 ◎ Let V be the result of converting the value of the entry to an ECMAScript value.
      2. %P := ~entryの~key ◎ Let P be the entry’s key.
    3. ~RET %O ◎ Return O.
    ~list◎a list
    1. %A := 式 `[]^c で作成されるものと同じ,新たな `Array^t ~obj ◎ Let A be a new Array object created as if by the expression [].
    2. %index :← 0 ◎ Let index be 0.
    3. ~WHILE %index < %S 内の要素~数: ◎ While index is less than the number of elements in S:

      1. %V := %S 内の~index %index に位置する要素の値を`直列化値toES^した結果 ◎ Let V be the result of converting the value of the element in S at index index to an ECMAScript value.
      2. %P := `ToString$A( %index ) ◎ Let P be ToString(index).
      3. `CreateDataProperty$A( %A, %P, %V ) を~callする 【原文の %O を %A に修正】 ◎ Call CreateDataProperty(O, P, V).
    4. ~RET %A ◎ Return A.
    他の直列化形の値◎any other serialized value
    1. ~RET %S を~JS値に`toES^した結果 ◎ Let V be the result of converting S to an ECMAScript value. ◎ Return V.

4.6.8. 反復子に共通する挙動

4.6.8.1. ~iterator0

所与の`~ifc$が,次のいずれかを持つならば…: ◎ If the interface has any of the following:

  • `可反復~宣言$ ◎ an iterable declaration
  • `有index~prop取得子$, および[ 名前 `length^c の,`整数~型$の`属性$ ] ◎ an indexed property getter and an integer-typed attribute named “length”
  • `~maplike 宣言$ ◎ a maplike declaration
  • `~setlike 宣言$ ◎ a setlike declaration

…ならば、次の特徴を有する~propが存在し~MUST:

  • 名前は `~iterator0^l ~symbol
◎ then a property MUST exist whose name is the @@iterator symbol, with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is a function object.

~prop値 %F は、次で与えられる: ◎ ↓

~ifcは `有index~prop取得子$を定義している場合: ◎ ↓
`ArrayProto_values^ ( `ECMA-262$r 6.1.7.4 節)。 ◎ If the interface defines an indexed property getter, then the Function object is %ArrayProto_values% ([ECMA-262], section 6.1.7.4).
~ifcは`~pair反復子$を持つ場合: ◎ If the interface has a pair iterator, then the Function, when invoked, MUST behave as follows:

被呼出時には次に従って挙動し~MUST: ◎ ↑

  1. %object := `this^v 値~上の `ToObject$A を~callした結果 ◎ Let object be the result of calling ToObject on the this value.
  2. ~IF %object は `~platform~obj$である ~THEN ( %object, %F, `~iterator0^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If object is a platform object, then perform a security check, passing: • the platform object object, • the ECMAScript global environment associated with this Function, • the identifier “@@iterator”, and • the type “method”.
  3. %interface := `可反復~宣言$が宣言されている`~ifc$ ◎ Let interface be the interface the iterable declaration is on.
  4. ~IF %object は[ %interface を実装する`~platform~obj$ ]でない ~THEN ~THROW `TypeError^t ◎ If object is not a platform object that implements interface, then throw a TypeError.
  5. ~RET [ %interface, ~target %object, 反復子の種類 `key+value^C ]に対し,新たに作成した`既定の反復子~obj$ ◎ Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “key+value”. ◎ Return iterator.
~ifcは `~maplike 宣言$/`~setlike 宣言$を持つ場合: ◎ If the interface has a maplike declaration or setlike declaration, then the Function object that is the value of the @@iterator property, when invoked, MUST behave as follows:
  1. ~IF %object は[ `~maplike 宣言$ / `~setlike 宣言$ を定義する`~ifc$を実装する`~platform~obj$ ]でない ~THEN ~THROW `TypeError^t ◎ If object is not a platform object that implements the interface on which the maplike declaration or setlike declaration is defined, then throw a TypeError.
  2. ~IF ~ifcは`~maplike 宣言$を持つ ⇒ ◎ If the interface has a maplike declaration, then:

    1. %backing := %object の `BackingMap^es `internal_slot^の値 ◎ Let backing be the value of the [[BackingMap]] internal slot of object.
    2. ~RET `CreateMapIterator$A(%backing, `key+value^l) ◎ Return CreateMapIterator(backing, "key+value").
  3. ~ELSE ⇒ ◎ Otherwise:

    1. %backing := %object の `BackingSet^es `internal_slot^の値 ◎ Let backing be the value of the [[BackingSet]] internal slot of object.
    2. ~RET `CreateSetIterator$A(%backing, `value^l) ◎ Return CreateSetIterator(backing, "value").

%F の `length^l ~propの値は、 `Number^t 値 `0^v である。 ◎ The value of the @@iterator Function object’s “length” property is the Number value 0.

%F の `name^l ~propの値は、当の~ifcが[[ `~pair反復子$ / `~maplike 宣言$ ]を持つならば `String^t 値 `entries^l / `~setlike 宣言$を持つならば `String^t 値 `values^l ]である。 ◎ The value of the @@iterator Function object’s “name” property is the String value “entries” if the interface has a pair iterator or a maplike declaration and the String “values” if the interface has a setlike declaration.

4.6.8.2. forEach

`~ifc$が次のいずれかを持つならば: ◎ If the interface has any of the following:

  • `可反復~宣言$ ◎ an iterable declaration
  • `~maplike 宣言$ ◎ a maplike declaration
  • `~setlike 宣言$ ◎ a setlike declaration

…ならば、次の特徴を有する~propが存在し~MUST:

  • 名前は `forEach^l
◎ then a property named “forEach” MUST exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.
~ifcは `有index~prop取得子$を定義している場合: ◎ ↓
`ArrayProto_values^ ( `ECMA-262$r 6.1.7.4 節)の `forEach^l ~data-propの初期~値。 ◎ If the interface defines an indexed property getter, then the Function object is the initial value of the “forEach” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
~ifcは `~pair反復子$を持つ場合:

[ その~ifcが,その`~pair反復子$を代わりに 次に示す[ `演算$, および注釈文による定義 ]を持つと見なしたときに,存在することになるものと同じ~挙動: ◎ If the interface has a pair iterator, then the Function MUST have the same behavior as one that would exist assuming the interface had this operation instead of the iterable declaration:

void forEach(Function %callback, optional any %thisArg);

◎ with the following prose definition:

  1. %O := `this^v 値 ◎ Let O be the this value.
  2. %pairs := `反復される値~pair$の~list ◎ Let pairs be the list of value pairs to iterate over.
  3. ~FOR %pairs 内の~EACH ( %pairs ) に対し,順に: ◎ Let i be 0. ◎ While i is less than the length of pairs:

    1. %pair := %pairs 内で~index %i に位置する~entry ◎ Let pair be the entry in pairs at index i.
    2. %key := %pair の~key ◎ Let key be pair’s key.
    3. %value := %pair の値 ◎ Let value be pair’s value.
    4. `呼戻 this 値$に %thisArg (引数が渡されなかった場合は `undefined^v )を, 引数に ( %value, %key, %O ) を渡して, %callback を呼出す ◎ Invoke callback with thisArg (or undefined, if the argument was not supplied) as the callback this value and value, key and O as its arguments.
    5. 現在の`反復される値~pair$の~listに %pairs で更新する ◎ Update pairs to the current list of value pairs to iterate over. ◎ Set i to i + 1.
~ifcは `~maplike 宣言$/`~setlike 宣言$を持つ場合: ◎ If the interface has a maplike declaration or setlike declaration then the Function, when invoked, MUST behave as follows:
  1. ~IF %object は `~platform~obj$である ~THEN ( %object, %F, `forEach^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If object is a platform object, then perform a security check, passing: • the platform object object, • the ECMAScript global environment associated with this Function, • the identifier “forEach”, and • the type “method”.
  2. %interface := `~maplike 宣言$/`~setlike 宣言$が宣言されている`~ifc$ ◎ Let interface be the interface on which the maplike declaration or setlike declaration is declared.
  3. %callbackFn := [ この関数に引数が渡されているならば その第一~引数の値 / ~ELSE_ `undefined^v ] ◎ Let callbackFn be the value of the first argument passed to the function, or undefined if the argument was not supplied.
  4. ~IF `IsCallable$A( %callbackFn ) ~EQ `false^v ~THEN ~THROW `TypeError^t ◎ If IsCallable(callbackFn) is false, throw a TypeError.
  5. %thisArg := [ 関数に第二~引数が渡されているならば その引数の値 / ~ELSE `undefined^v ] ◎ Let thisArg be the value of the second argument passed to the function, or undefined if the argument was not supplied.
  6. %backing := ~ifcが[ `~maplike 宣言$ / `~setlike 宣言$ ]のいずれを持つかに応じて, %object の[ `BackingMap^es / `BackingSet^es ]`internal_slot^ の値 ◎ Let backing be the value of the [[BackingMap]] internal slot of object, if the interface has a maplike declaration, or the [[BackingSet]] internal slot of object otherwise.
  7. %callbackWrapper := 被呼出時に次に従って挙動する `Function^t : ◎ Let callbackWrapper be a Function that, when invoked, behaves as follows:

    1. %v, %k := 順に,関数に渡された 最初の, 第二~引数 ◎ Let v and k be the first two arguments passed to the function.
    2. %thisArg := `this^v 値 ◎ Let thisArg be the this value.
    3. [ ~thisArg: %thisArg, ~argList: ( %v, %k, %object ) ]を渡して %callbackFn の`Call^es 内的~methを~callする ◎ Call the [[Call]] internal method of callbackFn with thisArg as thisArgument and v, k and object as argumentsList.

    %callbackWrapper 関数は、単純に,第三~引数に %object を渡して ~~入力の %callbackFn を~callする — その内的[ `BackingMap^es / `BackingSet^es ]~objではなく。 ◎ The callbackWrapper function simply calls the incoming callbackFn with object as the third argument rather than its internal [[BackingMap]] or [[BackingSet]] object.

    ~script作者は、[ forEach が~callされる度に, %callbackWrapper が新たな関数になる ]かどうか,観測し得るだろうか? [ 環境を capture した唯一の関数が在ること ]を指定する仕方として,何が最良になるだろうか? ◎ Can the script author observe that callbackWrapper might be a new function every time forEach is called? What's the best way of specifying that there's only one function that has captured an environment?

  8. %forEach := ( `forEach^l, %backing ) を引数に, %backing の `Get^es~内的~methを~callした結果 ◎ Let forEach be the result of calling the [[Get]] internal method of backing with “forEach” and backing as arguments.
  9. ~IF `IsCallable$A( %forEach ) ~EQ `false^v ~THEN ~THROW `TypeError^t ◎ If IsCallable(forEach) is false, throw a TypeError.
  10. [ ~thisArg: %backing, ~argList: ( %callbackWrapper, %thisArg ) ]を渡して %forEach の `Call^es 内的~methを~callする ◎ Call the [[Call]] internal method of forEach with backing as thisArgument and callbackWrapper and thisArg as argumentsList.
  11. ~RET `undefined^v ◎ Return undefined.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `forEach^l である。 ◎ The value of the Function object’s “name” property is the String value “forEach”.

4.6.9. 可反復~宣言

4.6.9.1. entries

`可反復~宣言$を持つ`~ifc$には、次の特徴を有する~propが存在し~MUST:

  • 名前は `entries^l
◎ If the interface has an iterable declaration, then a property named “entries” MUST exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.
~ifcは`値~反復子$を持つ場合:
`ArrayProto_values^ ( `ECMA-262$r 6.1.7.4 節)の `entries^l ~data-propの初期~値。 ◎ If the interface has a value iterator, then the Function object is the initial value of the “entries” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
~ifcは`~pair反復子$を持つ場合:
`iterator_symbol^ ~propの値で与えられる `Function^t ~obj。 ◎ If the interface has a pair iterator, then the Function object is the value of the @@iterator property.
4.6.9.2. keys

`可反復~宣言$を持つ`~ifc$には、次の特徴を有する~propが存在し~MUST:

  • 名前は `keys^l
◎ If the interface has an iterable declaration, then a property named “keys” MUST exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.
~ifcは`値~反復子$を持つ場合:
`ArrayProto_values^ ( `ECMA-262$r 6.1.7.4 節)の `keys^l ~data-propの初期~値。 ◎ If the interface has a value iterator, then the Function object is the initial value of the “keys” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
~ifcは`~pair反復子$を持つ場合: ◎ If the interface has a pair iterator, then the Function, when invoked, MUST behave as follows:
  1. ~IF %object は `~platform~obj$である ~THEN ( %object, %F, `keys^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If object is a platform object, then perform a security check, passing: • the platform object object, • the ECMAScript global environment associated with this Function, • the identifier “keys”, and • the type “method”.
  2. %interface := `可反復~宣言$が宣言されている`~ifc$ ◎ Let interface be the interface on which the iterable declaration is declared on.
  3. ~RET [ %interface, ~target %object, 反復子の種類 `key^C ]に対し,新たに作成した`既定の反復子~obj$ ◎ Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “key”. ◎ Return iterator.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `keys^l である。 ◎ The value of the Function object’s “name” property is the String value “keys”.

4.6.9.3. values

`可反復~宣言$を持つ`~ifc$には、次の特徴を有する~propが存在し~MUST:

  • 名前は `values^l
◎ If the interface has an iterable declaration, then a property named “values” MUST exist with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.
~ifcは`値~反復子$を持つ場合:
`iterator_symbol^ ~propの値で与えられる `Function^t ~obj。 ◎ If the interface has a value iterator, then the Function object is the value of the @@iterator property.
~ifcは`~pair反復子$を持つ場合: ◎ If the interface has a pair iterator, then the Function, when invoked, MUST behave as follows:
  1. ~IF %object は `~platform~obj$である ~THEN ( %object, %F, `entries^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If object is a platform object, then perform a security check, passing: • the platform object object, • the ECMAScript global environment associated with this Function, • the identifier “entries”, and • the type “method”.
  2. ~RET [ %interface, ~target %object, 反復子の種類 `value^C ]に対し,新たに作成した`既定の反復子~obj$ ◎ Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “value”. ◎ Return iterator.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `values^l である。 ◎ The value of the Function object’s “name” property is the String value “values”.

4.6.9.4. 既定の反復子~obj

所与の[ `~ifc$, ~target, 反復の種類 ]に対する `既定の反復子~obj@ とは、~objであって,その `Prototype^es 内的~prop が,その~ifcの`反復子~原型~obj$であるものである。 ◎ A default iterator object for a given interface, target and iteration kind is an object whose internal [[Prototype]] property is the iterator prototype object for the interface.

`既定の反復子~obj$は、次の3つの値を内的に持つ: ◎ A default iterator object has three internal values:

~target
反復される値を供給する~obj ◎ its target, which is an object whose values are to be iterated,
種類
反復の種類 【 `key^C, `value^C, `key+value^C のいずれか 】 ◎ its kind, which is the iteration kind,
~index
一連の値のうち,反復されることになる値を指す、現在の~index。 ◎ its index, which is the current index into the values value to be iterated.

既定の反復子~objは、`~pair反復子$のみに利用される — `値~反復子$は、現在は,~objの`被support~prop~index$上を反復するように制約されており、標準の~JS `Array^t 反復子~objを利用する。 ◎ Default iterator objects are only used for pair iterators; value iterators, as they are currently restricted to iterating over an object’s supported indexed properties, use standard ECMAScript Array iterator objects.

`既定の反復子~obj$が最初に作成されたときの~indexは、 0 にされる。 ◎ When a default iterator object is first created, its index is set to 0.

所与の`~ifc$に対する`既定の反復子~obj$の `~class文字列$は、[ その~ifcの`識別子$, 文字列 `Iterator^l ]の連結である。 ◎ The class string of a default iterator object for a given interface is the result of concatenting the identifier of the interface and the string “ Iterator”.

4.6.9.5. 反復子~原型~obj

`~pair反復子$を持つどの`~ifc$に対しても、 `反復子~原型~obj@ と呼ばれる~objが存在する。 それは、その~ifcに対する`既定の反復子~obj$の原型としての~~役割を担う。 ◎ The iterator prototype object for a given interface is an object that exists for every interface that has a pair iterator. It serves as the prototype for default iterator objects for the interface.

`反復子~原型~obj$の `Prototype^es 内的~propは、 `IteratorPrototype^ で~MUST。 ◎ The internal [[Prototype]] property of an iterator prototype object MUST be %IteratorPrototype% ([ECMA-262], section 6.1.7.4).

`反復子~原型~obj$は、次の特徴を有する~propを持た~MUST:

  • 名前は `next^l
  • 値は 下に与えるように挙動する`関数~obj$
◎ An iterator prototype object MUST have a property named “next” with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object that behaves as follows:
  1. %interface := その`反復子~原型~obj$が存在する`~ifc$ ◎ Let interface be the interface for which the iterator prototype object exists.
  2. ~IF %object は `~platform~obj$である ~THEN ( %object, この `Function^t, `next^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If object is a platform object, then perform a security check, passing: • the platform object object, • the ECMAScript global environment associated with this Function, • the identifier “next”, and • the type “method”.
  3. ~IF %object は %interface に対する`既定の反復子~obj$でない ~THEN ~THROW `TypeError^t ◎ If object is not a default iterator object for interface, then throw a TypeError.
  4. %target := %object の~target ◎ Let target be object’s target.
  5. %index := %object の~index ◎ Let index be object’s index.
  6. %kind := %object の種類 ◎ Let kind be object’s kind.
  7. %values := `反復される値~pair$の~list ◎ Let values be the list of value pairs to iterate over.

    【 変数 %target が~algoのどこにも利用されていない — この段で %values を供給する~objを指すと見られるが。 】

  8. %len := %values の長さ ◎ Let len be the length of values.
  9. ~IF %object の~index ≥ %len ~THEN ~RET `CreateIterResultObject$A(`undefined^v, `true^v) ◎ If object’s index is greater than or equal to len, then return CreateIterResultObject(undefined, true).
  10. %pair ~LET %values 内の %index に位置する~entry ◎ Let pair be the entry in values at index index.
  11. %result := %kind の値に応じて,次で決定される値: ◎ Let result be a value determined by the value of kind:

    `key^C
    1. %idlKey := %pair の~key ◎ Let idlKey be pair’s key.
    2. %key ~LET %idlKey を~JS値に`toES^した結果 ◎ Let key be the result of converting idlKey to an ECMAScript value.
    3. %result ← %key ◎ result is key.
    `value^C
    1. %idlValue := %pair の~key ◎ Let idlValue be pair’s value.
    2. %value := %idlValue を~JS値に`toES^した結果 ◎ Let value be the result of converting idlValue to an ECMAScript value.
    3. %result ← %value ◎ result is value.
    `key+value^C
    1. %array := `ArrayCreate$A( 2 ) を遂行した結果 ◎ Let array be the result of performing ArrayCreate(2).
    2. `CreateDataProperty$A( %array, `0^l, %key ) を~callする ◎ Call CreateDataProperty(array, "0", key).
    3. `CreateDataProperty$A( %array, `1^l, %value ) を~callする ◎ Call CreateDataProperty(array, "1", value).
    4. %result ← %array ◎ result is array.
  12. ~RET `CreateIterResultObject$A( %result, `false^v ) ◎ Return CreateIterResultObject(result, false).

所与の`~ifc$に対する`反復子~原型~obj$の `~class文字列$は[ その~ifcの`識別子$, 文字列 `Iterator^l ]の連結である。 ◎ The class string of an iterator prototype object for a given interface is the result of concatenting the identifier of the interface and the string “Iterator”.

4.6.10. ~maplike 宣言

`~maplike 宣言$を持つ`~ifc$ — この節を通して, %A と記される — を実装する どの~objも, `BackingMap^es `internal_slot^ を持た~MUST。 — それは、初期~時には,新たに作成された `Map^t ~objに設定される。 この `Map^t ~objの `MapData^es 内的~slotが,~objの一連の`~map~entry$になる。 ◎ Any object that implements an interface that has a maplike declaration MUST have a [[BackingMap]] internal slot, which is initially set to a newly created Map object. This Map object’s [[MapData]] internal slot is the object’s map entries.

%A の`~ifc原型~obj$上には、いくつかの追加の~propが存在する。 これらの追加の~propは、以下の各 下位~節にて述べられる。 ◎ If an interface A is declared with a maplike declaration, then there exists a number of additional properties on A’s interface prototype object. These additional properties are described in the sub-sections below.

それらの~propのうち一部のものは、以下において[ 所与の関数~名に対し, `内的~map~objへ転送する@ ような`関数~obj$ 値を持つ ]ように定義される。 その種の関数は、被呼出時に次に従って挙動する: ◎ Some of the properties below are defined to have a function object value that forwards to the internal map object for a given function name. Such functions behave as follows when invoked:

  1. %arguments := 関数に渡された引数の~list ◎ Let arguments be the list of arguments passed to this function.
  2. %name := 関数~名 ◎ Let name be the function name.
  3. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, %name, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • an identifier equal to name, and • the type “method”.
  4. ~IF %O は %A を実装する~objでない ~THEN ~THROW `TypeError^t ◎ If O is not an object that implements A, then throw a TypeError.
  5. %map := %O の `BackingMap^es `internal_slot^ の値である `Map^t ~obj ◎ Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
  6. %function := ( %name, %map ) を引数に, %map の `Get^es 内的~methを~callした結果 ◎ Let function be the result of calling the [[Get]] internal method of map passing name and map as arguments.
  7. ~IF `IsCallable$A( %function ) ~EQ `false^v ~THEN ~THROW `TypeError^t ◎ If IsCallable(function) is false, then throw a TypeError.
  8. ~RET [ ~thisArg: %map, ~argList: %arguments ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Return the result of calling the [[Call]] internal method of function with map as thisArg and arguments as argumentsList.
4.6.10.1. size

%A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ There MUST exist a property named “size” on A’s interface prototype object with the following characteristics:

  • 名前は `size^l ◎ ↑
  • 属性 { [[Get]]: %G, [[Enumerable]]: `false^v, [[Configurable]]: `true^v } を持つ。 ここで %G は、次項にて定義される `~map~size取得子@ である。 ◎ The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, where G is the interface’s map size getter, defined below.
  • `~map~size取得子$は、被呼出時の挙動が次で与えられる, `Function^t ~obj: ◎ The map size getter is a Function object whose behavior when invoked is as follows:

    1. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, `size^l, `取得子^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • the identifier “size”, and • the type “getter”.
    2. ~RET ( `size^l, %map ) を引数に, %map の `Get^es 内的~methを~callした結果 ◎ Return the result of calling the [[Get]] internal method of map passing “size” and map as arguments.

    この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `size^l である。 ◎ The value of the Function object’s “name” property is the String value “size”.

4.6.10.2. entries

%A の`~ifc原型~obj$上には、次の特徴を有する~propが存在し~MUST:

  • 名前は `entries^l
  • 値は `iterator_symbol^ ~propの値で与えられる`関数~obj$
◎ A property named “entries” MUST exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of the @@iterator property.
4.6.10.3. keys, values

名前[ `keys^l / `values^l ]に対しては、 %A の`~ifc原型~obj$上には,次の特徴を有する 同じ名前の~propが存在し~MUST。 ◎ For both of “keys” and “values”, there MUST exist a property with that name on A’s interface prototype object with the following characteristics:

  • 属性 `TFT^desc を持つ。 ◎ The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
  • 値は `内的~map~objへ転送する$ `Function^t ~obj。 ◎ The value of the property is a Function object that forwards that name to the internal map object.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値[ `keys^l / `values^l ]である。 ◎ The value of the Function object’s “name” property is the String value “keys” or “values”, correspondingly.

4.6.10.4. get, has

名前[ `get^l / `has^l ]に対しては、 %A の`~ifc原型~obj$上には,次の特徴を有する 同じ名前の~propが存在し~MUST。 ◎ For both of “get” and “has”, there MUST exist a property with that name on A’s interface prototype object with the following characteristics:

  • 値は 被呼出時に次に従って挙動する `Function^t ~obj: ◎ The value of the property is a Function object that behaves as follows when invoked:

    1. %name := ~propの名前( `get^l または `has^l )。 ◎ Let name be the name of the property – “get” or “has”.
    2. %keyType := `~maplike 宣言$にて指定された~key型 ◎ Let keyType be the key type specified in the maplike declaration.
    3. %keyArg := [ この関数に引数が渡されているならば その第一~引数の値 / ~ELSE_ `undefined^v ] ◎ Let keyArg be the first argument passed to this function, or undefined if not supplied.
    4. %keyIDL := %keyArg を型 %keyType の~IDL値に`toIDL^した結果 ◎ Let keyIDL be the result of converting keyArg to an IDL value of type keyType.
    5. %key := %keyIDL を~JS値に`toES^した結果 ◎ Let key be the result of converting keyIDL to an ECMAScript value.
    6. ~RET [ ~thisArg: %map, ~argList: ( %key ) ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値[ `get^l / `has^l ]である。 ◎ The value of the Function object’s “name” property is the String value “get” or “has”, correspondingly.

4.6.10.5. clear

%A のどの`広義~帰結~ifc$も識別子 `clear^l の`~ifc~mb$を宣言しない, かつ %A は可書~maplike 宣言を伴って宣言されている場合、 %A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ If A and A’s consequential interfaces do not declare an interface member with identifier “clear”, and A was declared with a read–write maplike declaration, then a property named “clear” and the following characteristics MUST exist on A’s interface prototype object:

  • 名前は `clear^l ◎ ↑
  • 値は `内的~map~objへ転送する$`Function^t ~obj。 ◎ The value of the property is a Function object that forwards “clear” to the internal map object.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `clear^l である。 ◎ The value of the Function object’s “name” property is the String value “clear”.

4.6.10.6. delete

%A のどの`広義~帰結~ifc$も,識別子 `delete^l の`~ifc~mb$を宣言しない, かつ %A は可書~maplike 宣言を伴って宣言されている場合、 %A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ If A and A’s consequential interfaces do not declare an interface member with identifier “delete”, and A was declared with a read–write maplike declaration, then a property named “delete” and the following characteristics MUST exist on A’s interface prototype object:

  • 名前は `delete^l ◎ ↑
    1. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, `delete^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • the identifier “delete”, and • the type “method”.
    2. %function := ( `delete^l, %map ) を引数に, %map の `Get^es 内的~methを~callした結果 ◎ Let function be the result of calling the [[Get]] internal method of map passing “delete” and map as arguments.
    3. ~RET [ ~thisArg: %map, ~argList: ( %key ) ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `delete^l である。 ◎ The value of the Function object’s “name” property is the String value “delete”.

4.6.10.7. set

%A のどの`広義~帰結~ifc$も,[ 識別子 `set^l の`~ifc~mb$を宣言しない, かつ %A は可書~maplike 宣言を伴って宣言されている ]ならば、 %A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ If A and A’s consequential interfaces do not declare an interface member with identifier “set”, and A was declared with a read–write maplike declaration, then a property named “set” and the following characteristics MUST exist on A’s interface prototype object:

  • 名前は `set^l ◎ ↑
    1. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, `set^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • the identifier “set”, and • the type “method”.
    2. %keyType, %valueType := 順に,`~maplike 宣言$にて指定された~key型, ~value型 ◎ Let keyType and valueType be the key and value types specified in the maplike declaration.
    3. %function := ( `set^l, %map ) を引数に, %map の `Get^es 内的~methを~callした結果 ◎ Let function be the result of calling the [[Get]] internal method of map passing “set” and map as arguments.
    4. %valueArg :=[ この関数に第二~引数が渡されているならば その値 / ~ELSE_ `undefined^v ] ◎ Let valueArg be the second argument passed to this function, or undefined if not supplied.
    5. %valueIDL := %valueArg を型 %valueType の~IDL値に`toIDL^した結果 ◎ Let valueIDL be the result of converting valueArg to an IDL value of type valueType.
    6. %value := %valueIDL を~JS値に`toES^した結果 ◎ Let value be the result of converting valueIDL to an ECMAScript value.
    7. %result :=[ ~thisArg: %map, ~argList: ( %key, %value ) ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Let result be the result of calling the [[Call]] internal method of function with map as thisArg and key and value as argumentsList.
    8. `Assert$: %result は `中途完了$でない ◎ Assert: result is not an abrupt completion.
    9. ~RET %O ◎ Return O.

この `Function^t ~objの `length^l ~propの値は、 `Number^t 値 `2^v である。 ◎ The value of the Function object’s “length” property is the Number value 2.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `set^l である。 ◎ The value of the Function object’s “name” property is the String value “set”.

4.6.11. ~setlike 宣言

`~setlike 宣言$を持つ`~ifc$ — この節を通して, %A と記される — を実装するどの~objも, `BackingSet^es `internal_slot^ を持た~MUST — それは、初期~時には,新たに作成された `Set^t ~objに設定される。 この `Map^t ~objの `SetData^es 内的~slotが,~objの一連の`~set~entry$になる。 ◎ Any object that implements an interface that has a setlike declaration MUST have a [[BackingSet]] internal slot, which is initially set to a newly created Set object. This Set object’s [[SetData]] internal slot is the object’s set entries.

%A の`~ifc原型~obj$上には、いくつかの追加の~propが存在する。 これらの追加の~propは、以下の各 下位~節にて述べられる。 ◎ If an interface A is declared with a setlike declaration, then there exists a number of additional properties on A’s interface prototype object. These additional properties are described in the sub-sections below.

それらの~propのうち一部のものは、以下にて 所与の関数~名に対し, `内的~set~objへ転送する@ ような`関数~obj$ 値を持つように定義される。 その種の関数は、被呼出時に次に従って挙動する: ◎ Some of the properties below are defined to have a function object value that forwards to the internal set object for a given function name. Such functions behave as follows when invoked:

  1. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, %name, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • an identifier equal to name, and • the type “method”.
  2. %set := %O の `BackingSet^es `internal_slot^ の値である `Set^t ~obj ◎ Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.
  3. %function := ( %name, %set ) を引数に, %set の `Get^es 内的~methを~callした結果 ◎ Let function be the result of calling the [[Get]] internal method of set passing name and set as arguments.
  4. ~RET [ ~thisArg: %set, ~argList: %arguments ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Return the result of calling the [[Call]] internal method of function with set as thisArg and arguments as argumentsList.
4.6.11.1. size

%A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ There MUST exist a property named “size” on A’s interface prototype object with the following characteristics:

  • 名前は `size^l ◎ ↑
  • 属性 { [[Get]]: %G, [[Enumerable]]: `false^v, [[Configurable]]: `true^v } を持つ。 ここで %G は、下に定義される `~set~size取得子@ である。 ◎ The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, where G is the interface’s set size getter, defined below.

`~set~size取得子$は、被呼出時の挙動が次で与えられる, `Function^t ~objである: ◎ The set size getter is a Function object whose behavior when invoked is as follows:

  1. ~RET ( `size^l, %set ) を引数に, %set の `Get^es 内的~methを~callした結果 ◎ Return the result of calling the [[Get]] internal method of set passing “size” and set as arguments.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `size^l である。 ◎ The value of the Function object’s “name” property is the String value “size”.

4.6.11.2. values

%A の`~ifc原型~obj$上には、次の特徴を有する~propが存在し~MUST:

  • 名前は `values^l
  • 値は `iterator_symbol^ ~propの値で与えられる`関数~obj$
◎ A property named “values” MUST exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of the @@iterator property.
4.6.11.3. entries, keys

名前[ `entries^l / `keys^l, ]に対しては、 %A の`~ifc原型~obj$上には,次の特徴を有する 同じ名前の~propが存在し~MUST。 ◎ For both of “entries” and “keys”, there MUST exist a property with that name on A’s interface prototype object with the following characteristics:

  • 値は `内的~set~objへ転送する$ `Function^t ~obj。 ◎ The value of the property is a Function object that forwards that name to the internal set object.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値[ `entries^l / `keys^l ]である。 ◎ The value of the Function object’s “name” property is the String value “entries” or “keys”, correspondingly.

4.6.11.4. has

%A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST。 ◎ There MUST exist a property with named “has” on A’s interface prototype object with the following characteristics:

  • 名前は `has^l ◎ ↑
    1. ~IF %O は `~platform~obj$である ~THEN ( %O, この `Function^t, `has^l, `~meth^C ) に対し,`保安~検査を遂行する$ ◎ If O is a platform object, then perform a security check, passing: • the platform object O, • the ECMAScript global environment associated with this Function, • the identifier “has”, and • the type “method”.
    2. %type := `~setlike 宣言$にて指定された~value型 ◎ Let type be the value type specified in the setlike declaration.
    3. %function := ( `has^l, %set ) を引数に, %set の `Get^es 内的~methを~callした結果 ◎ Let function be the result of calling the [[Get]] internal method of set passing “has” and set as arguments.
    4. %arg := [ この関数に引数が渡されているならば その第一~引数の値 / ~ELSE_ `undefined^v ] ◎ Let arg be the first argument passed to this function, or undefined if not supplied.
    5. %idlValue := %arg を型 %type の~IDL値に `toIDL^した結果 ◎ Let idlValue be the result of converting arg to an IDL value of type type.
    6. ~RET [ ~thisArg: %set, ~argList: ( %value ) ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Return the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `has^l である。 ◎ The value of the Function object’s “name” property is the String value “has”.

4.6.11.5. add, delete

名前[ `add^l / `delete^l ]に対しては、次の2条件: ◎ For both of “add” and “delete”, if:

  • %A のどの`広義~帰結~ifc$も,その名前に合致する識別子を伴う`~ifc~mb$を宣言していない ◎ A and A’s consequential interfaces do not declare an interface member with a matching identifier, and
  • %A は可書`~maplike 宣言$を伴って宣言されている ◎ A was declared with a read–write setlike declaration,

がいずれも満たされるならば、 %A の`~ifc原型~obj$上には,次の特徴を有する 同じ名前の~propが存在し~MUST: ◎ then a property with that name and the following characteristics MUST exist on A’s interface prototype object:

    1. %name := ~propの名前( `add^l または `delete^l )。 ◎ Let name be the name of the property – “add” or “delete”.
    2. %type := `~setlike 宣言$に指定された値~型 ◎ Let type be the value type specified in the setlike declaration.
    3. %result := [ ~thisArg: %set, ~argList: ( %value ) ]を渡して %function の `Call^es 内的~methを~callした結果 ◎ Let result be the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.
    4. ~RET [ %name ~EQ `delete^l ならば %result / ~ELSE_ %O ] ◎ If name is "delete", then: • Return result. ◎ Otherwise: • Return O.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値[ `add^l / `delete^l ]である。 ◎ The value of the Function object’s “name” property is the String value “add” or “delete”, correspondingly.

4.6.11.6. clear

%A のどの`広義~帰結~ifc$も,合致する識別子を伴う`~ifc~mb$を宣言しない, かつ %A は可書~setlike 宣言を伴って宣言されている場合、 %A の`~ifc原型~obj$上には,次の特徴を有する~propが存在し~MUST: ◎ If A and A’s consequential interfaces do not declare an interface member with a matching identifier, and A was declared with a read–write setlike declaration, then a property named “clear” and the following characteristics MUST exist on A’s interface prototype object:

  • 名前は `clear^l ◎ ↑
  • 値は `内的~set~objへ転送する$ `Function^t ~obj。 ◎ The value of the property is a Function object that forwards “clear” to the internal set object.

この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `clear^l である。 ◎ The value of the Function object’s “name” property is the String value “clear”.

4.6.12. 可反復から~objを初期化する

~mapや~setの様な~ifcの模倣を試みる,一部の~objでは、構築子の~parameterとして可反復( “反復し得るもの” )を受容し,自身を以下に述べる仕方で初期化することが求められることになる。 この節では、その種の~objにて ~JS仕様と同じ仕方でそうするために呼出せる,~algoを提供して、組込みの `Map^t, `Set^t ~objと同じに挙動するようにする。 ◎ Some objects, which are attempting to emulate map- and set-like interfaces, will want to accept iterables as constructor parameters and initialize themselves in this way. Here we provide some algorithms that can be invoked in order to do so in the same way as in the ECMAScript spec, so that those objects behave the same as the built-in Map and Set objects.

可反復 %iterable から,~obj %destination に,追加子~meth名 %adder により, `~map要素を追加する@ ときは、次の手続きを遂行する: ◎ To add map elements from an iterable iterable to an object destination with adder method name adder, perform the following steps:

  1. ~IF `Type^( %destination ) ~NEQ `Object^t ~THEN ~THROW `TypeError^t ◎ If Type(destination) is not Object, then, throw a TypeError exception.
  2. ~IF %iterable は `不在$ ~THEN %iterable := `undefined^v ◎ If iterable is not present, let iterable be undefined.
  3. ~IF %iterable ~IN { `undefined^v, `null^v } ~THEN %iter := `undefined^v ◎ If iterable is either undefined or null, then let iter be undefined.
  4. ~ELSE ◎ Else,

    1. %adder := `Get^(%destination, %adder) の結果 ◎ Let adder be the result of Get(destination, adder).
    2. `ReturnIfAbrupt$A( %adder ) ◎ ReturnIfAbrupt(adder).
    3. ~IF `IsCallable$A( %adder ) ~EQ `false^v ~THEN ~THROW `TypeError^t ◎ If IsCallable(adder) is false, throw a TypeError exception.
    4. %iter := `GetIterator$A( %iterable ) の結果 ◎ Let iter be the result of GetIterator(iterable).
    5. `ReturnIfAbrupt$A( %iter ) ◎ ReturnIfAbrupt(iter).
  5. ~IF %iter ~EQ `undefined^v ~THEN ~RET ◎ If iter is undefined, then return.
  6. ~WHILE 無条件: ◎ Repeat

    1. %next := `IteratorStep$A( %iter ) の結果 ◎ Let next be the result of IteratorStep(iter).
    2. `ReturnIfAbrupt$A( %next ) ◎ ReturnIfAbrupt(next).
    3. ~IF %next ~EQ `false^v ~THEN ~RET `NormalCompletion$A( %destination ) ◎ If next is false, then return NormalCompletion(destination).
    4. %nextItem := `IteratorValue$A( %next ) ◎ Let nextItem be IteratorValue(next).
    5. `ReturnIfAbrupt$A( %nextItem ) ◎ ReturnIfAbrupt(nextItem).
    6. ~IF `Type^( %nextItem ) ~NEQ `Object^t ~THEN ~THROW `TypeError^t ◎ If Type(nextItem) is not Object, then throw a TypeError exception.
    7. %k := `Get^(%nextItem, `0^l) の結果 ◎ Let k be the result of Get(nextItem, '0').
    8. `ReturnIfAbrupt$A( %k ) ◎ ReturnIfAbrupt(k).
    9. %v := `Get^(%nextItem, `1^l) の結果 ◎ Let v be the result of Get(nextItem, '1').
    10. `ReturnIfAbrupt$A( %v ) ◎ ReturnIfAbrupt(v).
    11. %status := [ ~thisArg: %destination, ~argList: ( %k, %v ) ]を渡して %adder の `Call^es 内的~methを~callした結果 ◎ Let status be the result of calling the [[Call]] internal method of adder with destination as thisArgument and (k, v) as argumentsList.
    12. `ReturnIfAbrupt$A( %status ) ◎ ReturnIfAbrupt(status).

4.7. ~implements文

~ifc %A の`~ifc原型~obj$は、 %A のすべての`帰結~ifc$に対し、その~ifc原型~obj上に存在する[ `定数$, `属性$, `演算$ [ `可反復~宣言$ / `~maplike 宣言$ / `~setlike 宣言$ ]]のそれぞれについて,対応する~propの複製を持た~MUST。 演算に対しては、~propが `Function^t ~obj値を伴う~data-propである所では,~propの各~複製ごとに元のものと異なる `Function^t ~objを持た~MUST。 同様に,属性に対しても、~accessor~propの各~複製ごとに,その取得子に対し, また その設定子に対しても同様に、元のものと異なる `Function^t ~objを持た~MUST。 ◎ The interface prototype object of an interface A MUST have a copy of each property that corresponds to one of the constants, attributes, operations, iterable declarations, maplike declarations and setlike declarations that exist on all of the interface prototype objects of A’s consequential interfaces. For operations, where the property is a data property with a Function object value, each copy of the property MUST have distinct Function objects. For attributes, each copy of the accessor property MUST have distinct Function objects for their getters, and similarly with their setters.

[ ~implements文により 存在が与えられる複製 ]の値である `Function^t ~objの~callを通して,`演算$が呼出されたときは、その~objが,~~実際に[ その~propを持つ`~ifc原型~obj$に対応する`~ifc$を実装するもの ]であることを確認するために、 `this^v 値が検査される。 ◎ When invoking an operation by calling a Function object that is the value of one of the copies that exists due to an implements statement, the this value is checked to ensure that it is an object that implements the interface corresponding to the interface prototype object that the property is on.

例えば次の~IDL片を考える: ◎ For example, consider the following IDL:

interface A {
  void f();
};

interface B { };
B implements A;

interface C { };
C implements A;

( `B^T ではなく,)`A^T や `C^T を実装する~obj上で `B.prototype.f^c を~callした結果は、 `TypeError^T の投出になる。 しかしながら、 `B^T や `C^T を実装する~obj上では `A.prototype.f^c の~callは成功することになる。 これは、~JSにおいて~IDL演算の呼出がどのように働くかを定義する, `es-operations$sec の~algoにより取扱われる。 ◎ Attempting to call B.prototype.f on an object that implements A (but not B) or one that implements C will result in a TypeError being thrown. However, calling A.prototype.f on an object that implements B or one that implements C would succeed. This is handled by the algorithm in section 4.6.7 that defines how IDL operation invocation works in ECMAScript.

同様の挙動が~IDL`属性$に対応する取得子や設定子の `Function^t ~objにも要求され、`es-attributes$sec にて取扱われる。 ◎ Similar behavior is required for the getter and setter Function objects that correspond to an IDL attributes, and this is handled in section 4.6.6.

4.8. ~ifcを実装している~platform~obj

どの`~platform~obj$も、`初期~obj$とちょうど同じ様に,大域環境に属する。 各~platform~objがどの大域環境に(または、代理を通して,どの大域~objに)属するか,についての言明-は Web IDL を利用する仕様が責を負う。 ◎ Every platform object is associated with a global environment, just as the initial objects are. It is the responsibility of specifications using Web IDL to state which global environment (or, by proxy, which global object) each platform object is associated with.

1つ以上の~ifcを実装する~platform~objの `主~ifc@ とは、それが実装する[ `追補~ifc$でない~ifc ]のうち,継承階層において最も末端の~ifcである。 ~platform~objの `Prototype^es 内的~propの値は、`~platform~obj$が属する大域環境に属する,`主~ifc$の`~ifc原型~obj$である。 ◎ The primary interface of a platform object that implements one or more interfaces is the most-derived non-supplemental interface that it implements. The value of the internal [[Prototype]] property of the platform object is the interface prototype object of the primary interface from the platform object’s associated global environment.

所与の`~platform~obj$が属する大域環境は、その作成-後に `変化-@ し得る。 ~platform~objが属する大域環境が変化した場合、その `Prototype^es 内的~prop は,その新たな大域環境に属する `主~ifc$の`~ifc原型~obj$に,即時に更新され~MUST。 ◎ The global environment that a given platform object is associated with can change after it has been created. When the global environment associated with a platform object is changed, its internal [[Prototype]] property MUST be immediately updated to be the interface prototype object of the primary interface from the platform object’s newly associated global environment.

`Unforgeable$x 注釈付きの~ifcを実装する, かつ[ 自身が実装するどの~ifcも,`偽装不可$である`文字列化子$は持たない ]ような,どの~platform~objも、次の特徴を有する~propを持た~MUST: ◎ Every platform object that implements an [Unforgeable]-annotated interface and which does not have a stringifier that is unforgeable on any of the interfaces it implements MUST have a property with the following characteristics:

  • 値は、 `Object.prototype.toString^c の初期~値である, `ObjProto_toString^ ( `ECMA-262$r 6.1.7.4 節)。 ◎ The value of the property is %ObjProto_toString% ([ECMA-262], section 6.1.7.4), the initial value of Object.prototype.toString.

`Unforgeable$x 注釈付きの~ifcを実装する,どの~platform~objも、それが,[ それが実装するどの~ifc上にも,`偽装不可$である`直列化子$を持たない ]ならば、次の特徴を有する~propを持た~MUST: ◎ Every platform object that implements an [Unforgeable]-annotated interface and which does not have a serializer that is unforgeable on any of the interfaces it implements MUST have a property with the following characteristics:

  • 名前は `toJSON^l 。 ◎ The name of the property is “toJSON”.
  • 値は `undefined^v 。 ◎ The value of the property is undefined.

`Unforgeable$x 注釈付きの~ifcを実装する,どの~platform~objも、次の特徴を有する~propを持た~MUST: ◎ Every platform object that implements an [Unforgeable]-annotated interface MUST have a property with the following characteristics:

  • 名前は `valueOf^l 。 ◎ The name of the property is “valueOf”.
  • 値は 挙動が次で与えられる `Function^t ~obj: ◎ The value of the property is a Function object whose behavior is as follows:

    1. ~RET `this^v 値 ◎ Return the this value.

    この `Function^t ~objが `既定の偽装不可 valueOf 関数@ である。 ◎ This Function object is the default unforgeable valueOf function.

  • この `Function^t ~objの `name^l ~propの値は、 `String^t 値 `valueOf^l である。 ◎ The value of the Function object’s “name” property is the String value “valueOf”.

1個~以上の~ifcを実装する~platform~objの `~class文字列$は、~platform~objの`主~ifc$の`識別子$で~MUST。 ◎ The class string of a platform object that implements one or more interfaces MUST be the identifier of the primary interface of the platform object.

4.8.1. 有index~propと有名~prop

`~platform~obj$が実装する`~ifc$が[ `有index~propを~supportする$, または`有名~propを~supportする$ ]場合、その~objは,~objの[有index/有名]~propに対応する,追加の~propを持って現れることになる。 これらの~propは,~obj上の “真の” 自前の~propではないが、 `GetOwnProperty^es 内的~methにより公開されて見えるようにされる。 ◎ If a platform object implements an interface that supports indexed or named properties, the object will appear to have additional properties that correspond to the object’s indexed and named properties. These properties are not “real” own properties on the object, but are made to look like they are by being exposed by the [[GetOwnProperty]] internal method.

しかしながら, `Global$x / `PrimaryGlobal$x `拡張属性$が利用されている場合、有名~propは その~obj上ではなく,[ 原型鎖~内の~objである, `有名~prop~obj$ ]上に公開される。 ◎ However, when the [Global] or [PrimaryGlobal] extended attribute has been used, named properties are not exposed on the object but on another object in the prototype chain, the named properties object.

~objが`有index~propを~supportする$ような複数の~ifcを実装することは許容され得る。 しかしながら,そのような場合、[ ~objにおける`被support~prop~index$の定義が競合していたり,それらの~ifcのいずれかが その~platform~objに対する`追補~ifc$である ]場合に、[ ~objが持つように現れることになる追加の~prop ]がどれになるか, あるいは[ その有index~propに関する正確な挙動 ]がどうなるか,については、未定義である。 同じことは、有名~propについても該当する。 ◎ It is permissible for an object to implement multiple interfaces that support indexed properties. However, if so, and there are conflicting definitions as to the object’s supported property indices, or if one of the interfaces is a supplemental interface for the platform object, then it is undefined what additional properties the object will appear to have, or what its exact behavior will be with regard to its indexed properties. The same applies for named properties.

[ ~platform~objが実装する,継承階層において最も末端の~ifc ]上で定義される`有index~prop取得子$が、[ 配列~indexによる~objに対する~indexingの際の挙動 ]を定義する。 `有index~prop設定子$に対しても同様になる。 先祖の~ifcによる,これらの特殊~演算の定義は、この仕方で上書きできる。 ◎ The indexed property getter that is defined on the derived-most interface that the platform object implements is the one that defines the behavior when indexing the object with an array index. Similarly for indexed property setters. This way, the definitions of these special operations from ancestor interfaces can be overridden.

[ [有index/有名]~propを~supportする~ifc ]を実装する~platform~objは,fixed になれない: すなわち,その[ `Object.freeze^c, `Object.seal^c, `Object.preventExtensions^c ]いずれかが それらの~obj上で~callされた場合、これらの関数は `TypeError^t を`投出^し~MUST。 同様に,[ `Global$x / `PrimaryGlobal$x ]の利用により有名~propを公開する`~ifc原型~obj$も、上の3つの関数が~callされた際に, `TypeError^t を`投出^し~MUST。 ◎ Platform objects implementing an interface that supports indexed or named properties cannot be fixed; if Object.freeze, Object.seal or Object.preventExtensions is called on one of these objects, the function MUST throw a TypeError. Similarly, an interface prototype object that exposes named properties due to the use of [Global] or [PrimaryGlobal] also MUST throw a TypeError if one of the three functions above is called on it.

~objが有index~propを~supportしていることにより,存在しているかのように現れる各~propの名前を `配列~index~prop名@ という。 それは、次の~algoが ~true を返すような~prop名 %P である: ◎ The name of each property that appears to exist due to an object supporting indexed properties is an array index property name, which is a property name P such that Type(P) is String and for which the following algorithm returns true:

  1. ~IF `Type^(%P) ~NEQ `String^t ~THEN ~RET ~false ◎ ↑
  2. %i := `ToUint32$A( %P ) ◎ Let i be ToUint32(P).
  3. %s := `ToString$A( %i ) ◎ Let s be ToString(i).
  4. ~IF[ %s ~NEQ %P ]~OR[ %i ~EQ 2`32^sup − 1 ] ~THEN ~RET ~false ◎ If s ~NEQ P or i = 2^32 − 1, then return false.
  5. ~RET ~true ◎ Return true.

所与の~platform~obj %O 上の~prop名は, %O が次を満たす`~ifc$ %I を実装するとき, `偽装不可~prop名@ とされる:

  • %I はその~prop名を識別子とする`~ifc~mb$を持ち, かつ
  • その~mbは[ %O が実装するいずれかの~ifc ]上で`偽装不可$である。

~objが `Unforgeable$x 注釈付きの`~ifc$を実装する場合、[ `toString^l, `valueOf^l ]も,その~objにおいて`偽装不可~prop名$になる。

◎ A property name is an unforgeable property name on a given platform object if the object implements an interface that has an interface member with that identifier and that interface member is unforgeable on any of the interfaces that O implements. If the object implements an [Unforgeable]-annotated interface, then “toString” and “valueOf” are also unforgeable property names on that object.

所与の有名~propを~obj上に公開するかどうかは、 `有名~propの可視性判定~algo@ を利用して決定される。 一部の有名~propは、[ `OverrideBuiltins$x `拡張属性$が利用されたかどうか ]に依存して,~obj上に公開されなくなる。 この~algoは、 ( ~prop名 %P, ~obj %O ) を~~入力にとり,次に従って演算する: ◎ The named property visibility algorithm is used to determine if a given named property is exposed on an object. Some named properties are not exposed on an object depending on whether the [OverrideBuiltins] extended attribute was used. The algorithm operates as follows, with property name P and object O:

  1. ~IF %P は %O 上の`偽装不可~prop名$である ~THEN ~RET ~false ◎ If P is an unforgeable property name on O, then return false.
  2. ~IF %O が実装する ある~ifcに,[ 識別子 %P の, `Unforgeable$x 注釈付きの属性 ]が伴われている ~THEN ~RET ~false ◎ If O implements an interface with an [Unforgeable]-annotated attribute whose identifier is P, then return false.
  3. ~IF %P は %O の`被support~prop名$でない ~THEN ~RET ~false ◎ If P is not a supported property name of O, then return false.
  4. ~IF %O が実装する ある~ifcが, `OverrideBuiltins$x `拡張属性$を持つ ~THEN ~RET ~true ◎ If O implements an interface that has the [OverrideBuiltins] extended attribute, then return true.
  5. ~IF %O は 名前 %P の自前の~propを持つ ~THEN ~RET ~false ◎ If O has an own property named P, then return false.
  6. %prototype :← %O の `Prototype^es 内的~prop の値 ◎ Initialize prototype to be the value of the internal [[Prototype]] property of O.
  7. ~WHILE %prototype ~NEQ `null^v : ◎ While prototype is not null:

    1. ~IF[ %prototype は `有名~prop~obj$でない ]~AND[ %prototype は 名前 %P の自前の~propを持つ ] ~THEN ~RET ~false ◎ If prototype is not a named properties object, and prototype has an own property named P, then return false.
    2. %prototype ← %prototype の `Prototype^es 内的~prop の値 ◎ Set prototype to be the value of the internal [[Prototype]] property of prototype.
  8. ~RET ~true ◎ Return true.

これにより、有名~propを伴う~objに対する~prop解決が次の順序で行えるようになる: ◎ This should ensure that for objects with named properties, property resolution is done in the following order:

  1. 有index~prop ◎ Indexed properties.
  2. 偽装不可である属性/演算 ◎ Unforgeable attributes and operations.
  3. `OverrideBuiltins$x である場合: ◎ Then, if [OverrideBuiltins]:

    1. 有名~prop ◎ Named properties.
    2. 自前の~prop ◎ Own properties.
    3. 原型鎖からの~prop ◎ Properties from the prototype chain.
  4. 他の場合( `OverrideBuiltins$x でない場合): ◎ Otherwise, if not [OverrideBuiltins]:

    1. 自前の~prop ◎ Own properties.
    2. 原型鎖からの~prop ◎ Properties from the prototype chain.
    3. 有名~prop ◎ Named properties.

`取得子$の~supportは ~platform~obj `GetOwnProperty^es ~meth(`getownproperty$sec) により取扱われ、`設定子$については ~platform~obj `DefineOwnProperty^es ~meth(`defineownproperty$sec), および ~platform~obj `Set^es ~meth(`platformobjectset$sec) により取扱われる。 ◎ Support for getters is handled by the platform object [[GetOwnProperty]] method defined in section 4.8.3, and for setters by the platform object [[DefineOwnProperty]] method defined in section 4.8.7 and the platform object [[Set]] method defined in section 4.8.6.

4.8.2. PlatformObjectGetOwnProperty 抽象演算

抽象演算 PlatformObjectGetOwnProperty は、 ( ~obj %O, ~prop名 %P, 真偽~値 %ignoreNamedProps ) を~~渡して~callされたとき,次の手続きを遂行する: ◎ The PlatformObjectGetOwnProperty abstract operation performs the following steps when called with an object O, a property name P, and a boolean ignoreNamedProps value:

  1. ~IF[ %O は `有index~propを~supportする$ ]~AND[ %P は `配列~index~prop名$である ] ⇒ ◎ If O supports indexed properties and P is an array index property name, then:

    1. %index := `ToUint32$A( %P ) ◎ Let index be the result of calling ToUint32(P).
    2. ~IF %index は `被support~prop~index$である ⇒ ◎ If index is a supported property index, then:

      1. %operation := `有index~prop取得子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the indexed property getter.
      2. ~IF %operation は `識別子$を伴わずに定義されている ~THEN %value ← [ ~index %index に対し,~ifcの記述に挙げられている `有index~propの値を決定する$ 手続きを遂行した結果 ] ◎ If operation was defined without an identifier, then set value to the result of performing the steps listed in the interface description to determine the value of an indexed property with index as the index.
      3. ~ELSE ~THEN %value ← [ ( %index ) を引数に, %operation の記述に挙げられている手続きを遂行した結果 ] ◎ Otherwise, operation was defined with an identifier. Set value to the result of performing the steps listed in the description of operation with index as the only argument value.
      4.    `BTT-V^desc — ここで:
        • %B := [ %O が実装するある~ifcに,`有index~prop設定子$が伴われている ならば `true^v / ~ELSE_ `false^v ]
        ◎ Set desc.[[Value]] to the result of converting value to an ECMAScript value. ◎ If O implements an interface with an indexed property setter, then set desc.[[Writable]] to true, otherwise set it to false. ◎ Set desc.[[Enumerable]] and desc.[[Configurable]] to true. ◎ Return desc.
    3. %ignoreNamedProps ← ~true ◎ Set ignoreNamedProps to true.
  2. ~IF [ %O は `有名~propを~supportする$ ]~AND[ %O は `Global$x / `PrimaryGlobal$x `拡張属性$を伴う`~ifc$を実装しない ]~AND[ ( ~prop名 %P, ~obj %O ) を~~入力に,`有名~propの可視性判定~algo$を走らせた結果 ~EQ ~true ]~AND[ %ignoreNamedProps ~EQ ~false ] ⇒ ◎ If O supports named properties, O does not implement an interface with the [Global] or [PrimaryGlobal] extended attribute, the result of running the named property visibility algorithm with property name P and object O is true, and ignoreNamedProps is false, then:

    1. %operation := `有名~prop取得子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the named property getter.
    2.    `BET-V^desc — ここで:
      • %B := [ %O が実装するある~ifcに,`有名~prop設定子$が伴われている ならば `true^v / ~ELSE_ `false^v ]
      • %E := [ %O が実装するある~ifcに, `LegacyUnenumerableNamedProperties$x `拡張属性$が伴われているならば `false^v / ~ELSE_ `true^v ]
      ◎ Set desc.[[Value]] to the result of converting value to an ECMAScript value. ◎ If O implements an interface with a named property setter, then set desc.[[Writable]] to true, otherwise set it to false. ◎ If O implements an interface with the [LegacyUnenumerableNamedProperties] extended attribute, then set desc.[[Enumerable]] to false, otherwise set it to true. ◎ Set desc.[[Configurable]] to true. ◎ Return desc.

4.8.3. ~platform~obj `GetOwnProperty^es ~meth

[ `有index~propを~supportする$, または`有名~propを~supportする$ ]`~ifc$を実装する どの`~platform~obj$ %O に対しても,その `GetOwnProperty^es 内的~methは、 ( ~prop名 %P ) を引数に~callされたときには,次に従って挙動し~MUST: ◎ The internal [[GetOwnProperty]] method of every platform object O that implements an interface which supports indexed or named properties MUST behave as follows when called with property name P:

  1. ~RET ( %O, %P, `false^v ) を引数に,抽象演算 `PlatformObjectGetOwnProperty^ を呼出した結果 ◎ Return the result of invoking the PlatformObjectGetOwnProperty abstract operation with O, P, and false as arguments.

4.8.4. ~platform~obj~有index~prop~設定子の呼出し

( ~prop~名 %P, ~JS値 %V ) を~~渡して `有index~prop設定子を呼出す@ ときは、次の手続きを遂行し~MUST: ◎ To invoke an indexed property setter with property name P and ECMAScript value V, the following steps MUST be performed:

  1. %creating := [ %index が`被support~prop~index$でないならば ~true / ~ELSE_ ~false ] ◎ Let creating be true if index is not a supported property index, and false otherwise.
  2. %operation := `有index~prop設定子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the indexed property setter.
  3. %T := %operation の第二~引数の型 ◎ Let T be the type of the second argument of operation.
  4. %value := %V を型 %T の~IDL値に`toIDL^した結果 ◎ Let value be the result of converting V to an IDL value of type T.
  5. ~IF %operation は `識別子$を伴わずに定義されている ⇒ ◎ If operation was defined without an identifier, then:

    1. ~IF %creating ~EQ ~true ~THEN ( ~index %index, 値 %value ) に対し,~ifcの記述に挙げられている `新たな有index~propを設定する$ 手続きを遂行する ◎ If creating is true, then perform the steps listed in the interface description to set the value of a new indexed property with index as the index and value as the value.
    2. ~ELSE ~THEN ( ~index %index, 値 %value ) に対し,~ifcの記述に挙げられている `既存の有index~propを設定する$ 手続きを遂行する ◎ Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing indexed property with index as the index and value as the value.
  6. ~ELSE ~THEN ( %index, %value ) を引数に, %operation の記述に挙げられている手続きを遂行する ◎ Otherwise, operation was defined with an identifier. Perform the steps listed in the description of operation with index and value as the two argument values.

4.8.5. ~platform~obj~有名~prop設定子の呼出し

( ~prop~名 %P, ~JS値 %V ) を~~渡して `有名~prop設定子を呼出す@ ときは、次の手続きを遂行し~MUST: ◎ To invoke a named property setter with property name P and ECMAScript value V, the following steps MUST be performed:

  1. %creating := [ %P は`被support~prop名$であるならば~true / ~ELSE_ ~false ] ◎ Let creating be true if P is not a supported property name, and false otherwise.
  2. %operation := `有名~prop設定子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the named property setter.
    1. ~IF %creating ~EQ ~true ~THEN ( 名前 %P, 値 %value ) に対し,~ifcの記述に挙げられている `新たな有名~propを設定する$ 手続きを遂行する ◎ If creating is true, then perform the steps listed in the interface description to set the value of a new named property with P as the name and value as the value.
    2. ~ELSE ~THEN ( 名前 %P, 値 %value ) に対し,~ifcの記述に挙げられている `既存の有名~propを設定する$ 手続きを遂行する ◎ Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing named property with P as the name and value as the value.

4.8.6. ~platform~obj `Set^es ~meth

[ `有index~propを~supportする$, または`有名~propを~supportする$ ]`~ifc$を実装する どの`~platform~obj$ %O に対しても,その `Set^es 内的~methは、 ( ~prop名 %P, 値 %V, ~JS言語~値 %Receiver ) を引数に~callされたときには,次に従って挙動し~MUST: ◎ The internal [[Set]] method of every platform object O that implements an interface which supports indexed or named properties MUST behave as follows when called with property name P, value V, and ECMAScript language value Receiver:

  1. ~IF %O ~EQ %Receiver ⇒ ◎ If O and Receiver are the same object, then:

    1. ~IF[ %O は `有index~propを~supportする$ ]~AND[ %P は`配列~index~prop名$である ]~AND[ %O が実装するある~ifcに,`有index~prop設定子$が伴われている ] ⇒ ◎ If O supports indexed properties, P is an array index property name, and O implements an interface with an indexed property setter, then:

      1. ( %P, %V ) を~~渡して `有index~prop設定子を呼出す$ ◎ Invoke the indexed property setter with P and V.
      2. ~RET `true^v ◎ Return true.
    2. ~IF[ %O は `有名~propを~supportする$ ]~AND[ `Type^( %P ) ~EQ `String^t ]~AND[ %P は`配列~index~prop名$である ]~AND[ %O が実装するある~ifcに,`有名~prop設定子$が伴われている ] ⇒ ◎ If O supports named properties, Type(P) is String, P is not an array index property name, and O implements an interface with a named property setter, then:

      1. ( %P, %V ) を~~渡して `有名~prop設定子を呼出す$ ◎ Invoke the named property setter with P and V.
      2. ~RET `true^v ◎ Return true.
  2. %ownDesc := ( %O, %P, `true^v ) を引数に,抽象演算 `PlatformObjectGetOwnProperty^ を呼出した結果。 ◎ Let ownDesc be the result of invoking the PlatformObjectGetOwnProperty abstract operation with O, P, and true as arguments.
  3. 既定の `Set^es 内的~meth の手続きにおける[ 段 3〜11 ]を遂行する( `ECMA-262$r, 9.1.9 節) ◎ Perform steps 3-11 of the default [[Set]] internal method ([ECMA-262], section 9.1.9).

4.8.7. ~platform~obj `DefineOwnProperty^es ~meth

[[ `有index~propを~supportする$, または`有名~propを~supportする$ ]`~ifc$を実装する`~platform~obj$ %O ]の `DefineOwnProperty^es 内的~methは,[ ~prop~key %P, *`~pdesc$( `ECMA-262$r 6.2.4 節) %Desc ]を伴って~callされたときは、次の手続きに従わ~MUST: ◎ When the internal [[DefineOwnProperty]] method of a platform object O that implements an interface which supports indexed or named properties is called with property key P and Property Descriptor ([ECMA-262], section 6.2.4) Desc, the following steps MUST be taken:

  1. ~IF[ %O は `有index~propを~supportする$ ]~AND[ %P は`配列~index~prop名$である ] ⇒ ◎ If O supports indexed properties and P is an array index property name, then:

    1. ~IF `IsDataDescriptor$A( %Desc ) を~callした結果 ~EQ `false^v ~THEN ~RET `false^v ◎ If the result of calling IsDataDescriptor(Desc) is false, then return false.
    2. ~IF %O が実装する どの~ifcにも,`有index~prop設定子$は伴われていない ~THEN ~RET `false^v ◎ If O does not implement an interface with an indexed property setter, then return false.
    3. ( %P, %Desc.`Value^es ) を~~渡して `有index~prop設定子を呼出す$ ◎ Invoke the indexed property setter with P and Desc.[[Value]].
    4. ~RET `true^v ◎ Return true.
  2. ~IF[ %O は `有名~propを~supportする$ ]~AND[ %O は `Global$x / `PrimaryGlobal$x `拡張属性$を伴う`~ifc$を実装しない ]~AND[ %P は %O の `Unforgeable$x ~prop名でない ] ⇒ ◎ If O supports named properties, O does not implement an interface with the [Global] or [PrimaryGlobal] extended attribute and P is not an unforgeable property name of O, then:

    1. ~IF[ %O が実装するある~ifcに, `OverrideBuiltins$x `拡張属性$が伴われている ]~OR[ %O は 名前 %P の自前の~propを持たない ] ⇒ ◎ If O implements an interface with the [OverrideBuiltins] extended attribute or O does not have an own property named P, then:

      1. ~IF[ %creating ~EQ ~false ]~AND[ %O が実装する どの~ifcにも,`有名~prop設定子$は伴われていない ] ~THEN ~RET `false^v ◎ If creating is false and O does not implement an interface with a named property setter, then return false.
      2. ~IF %O が実装する ある~ifcに,`有名~prop設定子$が伴われている ⇒ ◎ If O implements an interface with a named property setter, then:

        1. ( %P, %Desc.`Value^es ) を~~渡して `有名~prop設定子を呼出す$ ◎ Invoke the named property setter with P and Desc.[[Value]].
        2. ~RET `true^v ◎ Return true.
  3. ~IF %O は `Global$x / `PrimaryGlobal$x `拡張属性$を伴う`~ifc$を実装していない ~THEN %Desc.`Configurable^es ← `true^v ◎ If O does not implement an interface with the [Global] or [PrimaryGlobal] extended attribute, then set Desc.[[Configurable]] to true.
  4. ~RET `OrdinaryDefineOwnProperty$A( %O, %P, %Desc ) ◎ Return OrdinaryDefineOwnProperty(O, P, Desc).

4.8.8. ~platform~obj `Delete^es ~meth

[ `有index~propを~supportする$, または`有名~propを~supportする$ ] `~ifc$を実装する どの`~platform~obj$ %O においても,その `Delete^es 内的~methは、~prop名 %P を伴って~callされたときには,次に従って挙動し~MUST。 ◎ The internal [[Delete]] method of every platform object O that implements an interface which supports indexed or named properties MUST behave as follows when called with property name P.

    1. ~IF %index は `被support~prop~index$でない ~THEN ~RET `true^v ◎ If index is not a supported property index, then return true.
    2. ~RET `false^v ◎ Return false.
  1. ~IF[ %O は `有名~propを~supportする$ ]~AND[ %O は `Global$x / `PrimaryGlobal$x `拡張属性$を伴う`~ifc$を実装しない ]~AND[ ( ~prop名 %P, ~obj %O ) を~~入力に,`有名~propの可視性判定~algo$を~callした結果 ~EQ ~true ] ⇒ ◎ If O supports named properties, O does not implement an interface with the [Global] or [PrimaryGlobal] extended attribute and the result of calling the named property visibility algorithm with property name P and object O is true, then:

    1. ~IF %O が実装する どの~ifcにも,`有名~prop削除子$は伴われていない ~THEN ~RET `false^v ◎ If O does not implement an interface with a named property deleter, then false.
    2. %operation := `有名~prop削除子$の宣言-時に利用された演算 ◎ Let operation be the operation used to declare the named property deleter.
      1. 名前 %P に対し,既存の有名~propを削除するために、~ifcの記述に挙げられている `既存の有名~propを削除する$ 手続きを遂行する ◎ Perform the steps listed in the interface description to delete an existing named property with P as the name.
      2. ~IF 手続きから削除の失敗-が指示された ~THEN ~RET `false^v ◎ If the steps indicated that the deletion failed, then false.
    3. ~ELSE ⇒ ◎ Otherwise, operation was defined with an identifier:

      1. ( %P ) を引数に, %operation の記述に挙げられている手続きを遂行する ◎ Perform the steps listed in the description of operation with P as the only argument value.
      2. ~IF[ %operation は `返値型$ `boolean$T を伴って宣言されている ]~AND[ その手続きから `false^V が返された ] ~THEN ~RET `false^v ◎ If operation was declared with a return type of boolean and the steps returned false, then false.
    4. ~RET `true^v ◎ Return true.
  2. ~IF %O は 名前 %P の自前の~propを持つ ⇒ ◎ If O has an own property with name P, then:

    1. ~IF その~propは~configurableでない ~THEN ~RET `false^v ◎ If the property is not configurable, then false.
    2. ~ELSE ~THEN その~propを %O から除去する ◎ Otherwise, remove the property from O.

4.8.9. ~platform~obj `Call^es ~meth

少なくとも1つの`旧来呼出子$を伴う`~ifc$ %I を実装する,どの`~platform~obj$ %O においても,その `Call^es 内的~methは、 %arg0..%n−1 を `Call^es に渡される引数~値の~listとするとき,次に従って挙動し~MUST。 ◎ The internal [[Call]] method of every platform object O that implements an interface I with at least one legacy caller MUST behave as follows, assuming arg0..n−1 is the list of argument values passed to [[Call]]:

  1. %S :← %I 上の,[ 引数個数 %n ]の旧来呼出子からなる`有効~多重定義~集合$ ◎ Initialize S to the effective overload set for legacy callers on I and with argument count n.
  2. ( %values ) を引数に,旧来呼出子 %operation の記述に挙げられている手続きを遂行する ◎ Perform the actions listed in the description of the legacy caller operation with values as the argument values.
  3. ~RET [ その %operation の返値として宣言されている型が `void$T ならば `undefined^v / ~ELSE_ 前段の返値を~JS値に`toES^した結果 ] ◎ Return the result of converting the return value from those actions to an ECMAScript value of the type operation is declared to return (or undefined if operation is declared to return void).

4.8.10. ~prop列挙

この文書は、 `~ifc$を実装しているすべての`~platform~obj$に対する(または 例外を表現する~platform~obj に対する) 完全な~prop列挙~順序は定義しない。 しかしながら,~platform~objが[ `有index~propを~supportする$, または`有名~propを~supportする$ ]~ifcを実装する場合、その~obj上の~propは次の順序により列挙され~MUST: ◎ This document does not define a complete property enumeration order for all platform objects implementing interfaces (or for platform objects representing exceptions). However, if a platform object implements an interface that supports indexed or named properties, then properties on the object MUST be enumerated in the following order:

  1. 最初に,~objが`有index~propを~supportする$場合、その~objの`被support~prop~index$が数的~順序で列挙される。 ◎ If the object supports indexed properties, then the object’s supported property indices are enumerated first, in numerical order.
  2. 次に,~objが[ `有名~propを~supportする$, かつ `LegacyUnenumerableNamedProperties$x `拡張属性$を伴う~ifcは実装しない ]場合、その~objの被support~prop名のうち,[ `有名~propの可視性判定~algo$に従って可視であるもの ]が、`被support~prop名$の集合に(仕様により)定義された順序で列挙される。 ◎ If the object supports named properties and doesn't implement an interface with the [LegacyUnenumerableNamedProperties] extended attribute, then the object’s supported property names that are visible according to the named property visibility algorithm are enumerated next, in the order given in the definition of the set of supported property names.
  3. 最後に、自前の~prop, および~objの原型鎖からの~propのうち,列挙可能なものが未定義の順序で列挙される。 ◎ Finally, any enumerable own properties or properties from the object’s prototype chain are then enumerated, in no defined order.

~JS仕様の将来~versionでは~prop列挙のための全順序が定義され得る。 ◎ Future versions of the ECMAScript specification may define a total order for property enumeration.

4.9. 呼戻~ifcを実装する利用者~obj

上の `idl-objects$sec に述べたように、 `呼戻~ifc$は,~scriptの中で~JS~objにより実装され得る。 次の場合分けにより、所与の~objが[ 呼戻~ifcを実装している利用者~obj ]と見なされるかどうかが決定される。 ◎ As described in section 3.9 above, callback interfaces can be implemented in script by an ECMAScript object. The following cases determine whether and how a given object is considered to be a user object implementing a callback interface:

  • ~ifcが(下で定義される)`単一~演算~呼戻~ifc$である場合、 ~native `RegExp^t ~obj以外の どの~objも、その~ifcを実装するものと見なされる。 その演算(または多重定義されている演算の集合)の実装は次で与えられる: ◎ If the interface is a single operation callback interface (defined below) then any object apart from a native RegExp object is considered to implement the interface. The implementation of the operation (or set of overloaded operations) is as follows:

    • ~objが`~callable$である場合、その演算(または多重定義されている演算の集合)の実装はその~callable~obj自身になる。 ◎ If the object is callable, then the implementation of the operation (or set of overloaded operations) is the callable object itself.
    • 他の場合(すなわち~objは`~callable$でない)、その演算(または多重定義されている演算の集合)の実装は、その演算の`識別子$を~prop名 【†1】 として,その~obj上の `Get^es 内的~methを呼出した結果になる。 ◎ Otherwise, the object is not callable. The implementation of the operation (or set of overloaded operations) is the result of invoking the internal [[Get]] method on the object with a property name that is the identifier of the operation.
  • 他の場合( ~ifcは`単一~演算~呼戻~ifc$でない)、 ~native `RegExp^t ~obj以外の どの~objも、その~ifcを実装するものと見なされる。 所与の`識別子$を伴って~ifc上に宣言される各~演算に対し、その実装は,その識別子を~prop名として,その~obj上の `Get^es を呼出した結果になる。 ◎ Otherwise, the interface is not a single operation callback interface. Any object that is not a native RegExp object is considered to implement the interface. For each operation declared on the interface with a given identifier, the implementation is the result of invoking [[Get]] on the object with a property name that is that identifier.

`~ifc$上に`定数$が宣言されているとしても、~JS~objが,その~ifcを実装している`利用者~obj$と見なされるために,それらの定数に対応する~propを持つ必要はないことに注意。 ◎ Note that ECMAScript objects need not have properties corresponding to constants on them to be considered as user objects implementing interfaces that happen to have constants declared on them.

`単一~演算~呼戻~ifc@ とは、次のすべてを満たす`呼戻~ifc$である: ◎ A single operation callback interface is a callback interface that:

  • 別の~ifcを`継承-$するように宣言されていない, ◎ is not declared to inherit from another interface,
  • `属性$を持たない, ◎ has no attributes, and
  • すべてが同じ`識別子$を持つ1個~以上の`正則~演算$があり,他のものはない。 ◎ has one or more regular operations that all have the same identifier, and no others.

【 例えば DOM の `EventListener^T ~ifc。 その唯一の~mbの識別子 `handleEvent^c が上述の~prop名( †1 )にあたる。 】

【 共通の記述を集約するため、この訳では,以下に定義される手続きの一部を次の二つの手続き “PrepareSettings”, “GetCompletion” に~~分離する( 手続きの名前は、当たり障りないように選んだだけで特に意味はない): 】

`PrepareSettings@( %realm, %value ) は、次を遂行する:

  1. `関連する設定群^ := %realm の`設定群~obj$ ◎ Let relevant settings be realm's settings object.
  2. `格納済み設定群^ ~LET %value の`呼戻~文脈$ ◎ Let stored settings be value's callback context.
  3. `関連する設定群^ で`~scriptを走らすために準備する$ ◎ Prepare to run script with relevant settings.
  4. `格納済み設定群^ で`呼戻子を走らすために準備する$ ◎ Prepare to run a callback with stored settings.
  5. ~RET ( `関連する設定群^, `格納済み設定群^ )

`GetCompletion@( `関連する設定群^, `格納済み設定群^, %completion, %T ) は、次を遂行する:

  1. `格納済み設定群^ で,`走らせた呼戻子を片付ける$ ◎ Clean up after running a callback with stored settings.
  2. `関連する設定群^ で,`走らせた~scriptを片付ける$ ◎ Clean up after running script with relevant settings.
  3. ~IF %completion は正常完了である ~THEN ~RET %completion ◎ If completion is a normal completion, return completion.
  4. ~IF[ %completion は中途完了である ]~AND[ %T は`~promise型$でない ] ~THEN ~RET %completion ◎ If completion is an abrupt completion and T is not a promise type, return completion.
  5. %rejectedPromise := 次を与える下で[ `Promise^.reject の初期~値 ]を~callした結果:

    • `this^v 値: `Promise^
    • 引数~list: ( %completion.`Value^es )
    ◎ Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value.
  6. ~RET %rejectedPromise を %T 型~値に`toIDL^した結果 ◎ Return the result of converting rejectedPromise to T.

利用者~objの演算を~callする ときは、所与の:

  • `~ifc型$の値: %value
  • 演算~名: %opName( sometimes-随意) 【 “optional” に “sometimes-” が加わると何が変わるのか? 】
  • 引数~値の~list: %arg0..%n−1(各~引数は[ ~IDL値, または`MISSING^ (供されなかった随意~引数を表現する) ]をとる)
  • `呼戻 this 値@: %thisArg (随意)

に対し、次の~手続きを遂行する。 この手続きは、~IDL値を返すか,例外を投出する。

◎ To call a user object's operation, given a callback interface type value value, sometimes-optional operation name opName, list of argument values arg0..n−1 each of which is either an IDL value or the special value “missing” (representing a missing optional argument), and optional callback this value thisArg, perform the following steps. These steps will either return an IDL value or throw an exception.
  1. %completion :← 未初期化の変数 ◎ Let completion be an uninitialized variable.
  2. ~IF %thisArg は与えられていない ~THEN %thisArg := `undefined^v ◎ If thisArg was not given, let thisArg be undefined.
  3. %O := %value に対応している~JS~obj ◎ Let O be the ECMAScript object corresponding to value.
  4. %realm := %O が`属する~Realm$ ◎ Let realm be O's associated Realm.
  5. ( `関連する設定群^, `格納済み設定群^ ) ~LET `PrepareSettings$( %realm, %value ) ◎ • Let relevant settings be realm's settings object. • Let stored settings be value's callback context. • Prepare to run script with relevant settings. • Prepare to run a callback with stored settings.
  6. %T ~LET 当の演算の返値型 ◎ ↓
  7. 当の演算の実装 %X を決定する: ◎ Determine the implementation of the operation, X:

    1. ~IF[ %value の~ifcは、`単一~演算~呼戻~ifc$である ]~AND[ ! `IsCallable$A( %O ) ~EQ ~true ] ~THEN %X ← %O ◎ If value's interface is a single operation callback interface and ! IsCallable(O) is true, then set X to O.
    2. ~ELSE — %opName が供されてい~MUST: ◎ Otherwise, opName must be supplied:

      1. %getResult := `Get$A( %O, %opName ) ◎ Let getResult be Get(O, opName).
      2. ~IF %getResult は中途完了である: ~THEN ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %getResult, %T ) ◎ If getResult is an abrupt completion, set completion to getResult and jump to the step labeled return.
      3. %X ← %getResult.`Value^es ◎ Set X to getResult.[[Value]].
  8. ~IF ! `IsCallable$A( %X ) ~EQ `false^v :

    1. %completion ← 新たな `Completion${ `Type^es: throw, `Value^es: 新たな `TypeError^t ~obj, `Target^es: 空 }
    2. ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %completion, %T )
    ◎ If ! IsCallable(X) is false, then set completion to a new Completion{[[Type]]: throw, [[Value]]: a newly created TypeError object, [[Target]]: empty}, and jump to the step labeled return.
  9. ~IF[ %value の~ifcは`単一~演算~呼戻~ifc$でない ]~OR[ ! `IsCallable$A( %O ) ~EQ `false^v ] ~THEN %thisArg ← %O (提供された値を上書きする) ◎ If value's interface is not a single operation callback interface, or if ! IsCallable(O) is false, set thisArg to O (overriding the provided value).
  10. %esArgs := 空の~JS List 値 ◎ Let esArgs be an empty List of ECMAScript values.
  11. %i :← 0 ◎ Let i be 0.
  12. %count :← 0 ◎ Let count be 0.
    1. ~IF %arg%i ~EQ `MISSING^ ~THEN `undefined^v を %esArgs に付加する ◎ If argi is the special value “missing”, then append undefined to esArgs.
    2. ~ELSE( %arg%i は~IDL値である): ◎ Otherwise, argi is an IDL value:

      1. %convertResult := %arg%i を~JS値に`toES^した結果 ◎ Let convertResult be the result of converting argi to an ECMAScript value.
      2. ~IF %convertResult は中途完了である ~THEN ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %convertResult, %T ) ◎ If convertResult is an abrupt completion, set completion to convertResult and jump to the step labeled return.
      3. %convertResult .`Value^es を %esArgs に付加する ◎ Append convertResult.[[Value]] to esArgs.
      4. %count ← %i + 1 ◎ Set count to i + 1.
    3. %i ← %i + 1 ◎ Set i to i + 1.
  13. %esArgs を長さ %count 個に切り詰める ◎ Truncate esArgs to have length count.
  14. %callResult := `Call$A( %X, %thisArg, %esArgs ) ◎ Let callResult be Call(X, thisArg, esArgs).
  15. ~IF %callResult は中途完了である ~THEN ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %callResult, %T ) ◎ If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.
  16. %completion ← %callResult .`Value^es を %T 型~値に`toIDL^した結果 ◎ Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s return type.
  17. ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %completion, %T )

    ◎ Return: at this point completion will be set to an ECMAScript completion value. • Clean up after running a callback with stored settings. • Clean up after running script with relevant settings. • If completion is a normal completion, return completion. • If completion is an abrupt completion and the operation has a return type that is not a promise type, return completion. • Let reject be the initial value of %Promise%.reject. • Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value. • Return the result of converting rejectedPromise to the operation's return type.

利用者~objの属性~値を取得する ときは、所与の:

  • `~ifc型$の値: %object
  • 属性~名: %attributeName

に対し,次の手続きを遂行する。 この手続きは、~IDL値を返すか,例外を投出する。

◎ To get a user object's attribute value, given a callback interface type value object and attribute name attributeName, perform the following steps. These steps will either return an IDL value or throw an exception.
  1. %O := %object に対応している~JS~obj ◎ Let O be the ECMAScript object corresponding to object.
  2. ( `関連する設定群^, `格納済み設定群^ ) ~LET `PrepareSettings$( %realm, %object ) ◎ • Let relevant settings be realm's settings object. • Let stored settings be object's callback context. • Prepare to run script with relevant settings. • Prepare to run a callback with stored settings.
  3. %getResult := `Get$A( %O, %attributeName ) ◎ Let getResult be Get(O, attributeName).
  4. %completion ← %getResult.`Value^es を当の属性の型と同じ型の~IDL値に`toIDL^した結果 ◎ Set completion to the result of converting getResult.[[Value]] to an IDL value of the same type as the attribute's type.
  5. ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %completion, %T ) ◎ Return: at this point completion will be set to an ECMAScript completion value. • Clean up after running a callback with stored settings. • Clean up after running script with relevant settings. • If completion is a normal completion, return completion. • If completion is an abrupt completion and the attribute's type is not a promise type, return completion. • Let reject be the initial value of %Promise%.reject. • Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value. • Return the result of converting rejectedPromise to the attribute's type.

利用者~objの属性~値を設定する ときは、所与の:

  • `~ifc型$の値: %object
  • 属性~名: %attributeName
  • ~IDL値: %value

に対し,次の手続きを遂行する。 この手続きは、何も返さないが,例外を投出し得る。

◎ To set a user object's attribute value, given a callback interface type value object, attribute name attributeName, and IDL value value, perform the following steps. These steps will not return anything, but could throw an exception.
  1. ( `関連する設定群^, `格納済み設定群^ ) ~LET `PrepareSettings$( %realm, %object ) ◎ • Let relevant settings be realm's settings object. • Let stored settings be object's callback context. • Prepare to run script with relevant settings. • Prepare to run a callback with stored settings.
  2. %convertResult := %value を~JS値に`toES^した結果 ◎ Let convertResult be the result of converting value to an ECMAScript value.
  3. %completion ← `Set^( %O, %attributeName, %convertResult.`Value^es, `true^v ) ◎ Set completion to Set(O, attributeName, convertResult.[[Value]], true).
  4. `最終~段^i ( この時点で %completion は~JS~completion値に設定される。 値 `true^v に対し `Set^ から返される結果は,中途完了か正常完了である。) ◎ Return: at this point completion will be set to an ECMAScript completion value, which is either an abrupt completion or a normal completion for the value true (as returned by Set).

    1. `格納済み設定群^ で,`走らせた~scriptを片付ける$ ◎ Clean up after running a callback with stored settings.
    2. `関連する設定群^ で,`走らせた~scriptを片付ける$ ◎ Clean up after running script with relevant settings.
    3. ~IF %completion は中途完了である ~THEN ~RET %completion ◎ If completion is an abrupt completion, return completion.
    4. ~RET `NormalCompletion$A( `void$T ) ◎ Return NormalCompletion(void).

4.10. 呼戻~関数の呼出し

`呼戻~関数$値として利用されている~JS`~callable$~objの~callのされ方は、前~節で述べた,`利用者~obj$上の`演算$の~callと同様である。 ◎ An ECMAScript callable object that is being used as a callback function value is called in a manner similar to how operations on user objects are called (as described in the previous section).

呼戻~関数を呼出す ときは、所与の:

  • `呼戻~関数~型$の値: %callable
  • 引数~list: %arg0..%n−1 (各~引数は[ ~IDL値, または `MISSING^ (供されなかった随意~引数を表現する) ]をとる)
  • `呼戻 this 値$: %thisArg

に対し,次の手続きを遂行する。 この手続きは、~IDL値を返すか,例外を投出する。

◎ To invoke a callback function type value callable with a list of arguments arg0..n−1, each of which is either an IDL value or the special value “missing” (representing a missing optional argument), and with optional callback this value thisArg, perform the following steps. These steps will either return an IDL value or throw an exception.
  1. %F := %value に対応している~JS~obj ◎ Let F be the ECMAScript object corresponding to value.
  2. %T ~LET 当の呼戻~関数の返値型 ◎ ↓
  3. ~IF ! `IsCallable$A( %F ) ~EQ `false^v : ◎ If ! IsCallable(F) is false:

    1. ~IF %T ~EQ `void$T ~THEN ~RET ◎ If the callback function's return type is void, return.

      これが生じるのは、 `TreatNonObjectAsNull$x が付与された属性による呼戻~関数に限られる。 ◎ This is only possible when the callback function came from an attribute marked with [TreatNonObjectAsNull].

    2. ~RET `undefined^v を %T 型~値に`toIDL^した結果 ◎ Return the result of converting undefined to the callback function's return type.
  4. %realm := %F が`属する~Realm$ ◎ Let realm be F's associated Realm.
  5. ( `関連する設定群^, `格納済み設定群^ ) ~LET `PrepareSettings$( %realm, %callable ) ◎ • Let relevant settings be realm's settings object. • Let stored settings be callable's callback context. • Prepare to run script with relevant settings. • Prepare to run a callback with stored settings.
  6. %i :← 0 ◎ Let i be 0.
  7. %count :← 0 ◎ Let count be 0.
    1. %i ← %i + 1 ◎ Set i to i + 1.
  8. ~RET `GetCompletion$( `関連する設定群^, `格納済み設定群^, %completion, %T ) ◎ Return: at this point completion will be set to an ECMAScript completion value. • Clean up after running a callback with stored settings. • Clean up after running script with relevant settings. • If completion is a normal completion, return completion. • If completion is an abrupt completion and the callback function has a return type that is not a promise type, return completion. • Let reject be the initial value of %Promise%.reject. • Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value. • Return the result of converting rejectedPromise to the callback function's return type.

4.11. 例外

~JS大域~obj上には、次の特徴を有する~propが存在し~MUST:

  • 名前は `DOMException^l
  • 値は `DOMException 構築子~obj@ と呼ばれる~obj(次節にて述べる)

それは、旧来の DOMException ~code定数への~accessを提供し, `DOMException$T の~instanceを構築できるようにする。

◎ There MUST exist a property on the ECMAScript global object whose name is “DOMException” and value is an object called the DOMException constructor object, which provides access to legacy DOMException code constants and allows construction of DOMException instances. The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

4.11.1. DOMException 構築子~obj

`DOMException 構築子~obj$は、 `Prototype^es 値 `Error^ ( `ECMA-262$r 6.1.7.4 節)は伴わない,関数~objで~MUST。 ◎ The DOMException constructor object MUST be a function object but with a [[Prototype]] value of %Error% ([ECMA-262], section 6.1.7.4).

`~error名~一覧$に挙げられた どの旧来~codeに対しても, `DOMException 構築子~obj$上に,次の特徴を有する~propが存在し~MUST:

  • その名前と値は、一覧に指示されている名前と値
  • 属性 `FTF^desc を持つ
◎ For every legacy code listed in the error names table, there MUST be a property on the DOMException constructor object whose name and value are as indicated in the table. The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

`DOMException 構築子~obj$は、次の特徴を有する~propを持た~MUST:

  • 値は `DOMException 原型~obj@ と呼ばれる~obj( `es-DOMException-prototype-object$secにて述べる)

この~objは、その例外~上に宣言されている旧来~code値への~accessも提供する。

◎ The DOMException constructor object MUST also have a property named “prototype” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is an object called the DOMException prototype object. This object also provides access to the legacy code values.
4.11.1.1. DOMException(%message, %name)

DOMException 関数が,引数 ( %message, %name ) を伴って,~callされたときは、次の手続きを行う: ◎ When the DOMException function is called with arguments message and name, the following steps are taken:

  1. %F := the active 関数~obj the active function object ◎ Let F be the active function object.
  2. %newTarget := [ NewTarget ~EQ `undefined^v ならば %F / ~ELSE_ NewTarget ] `NewTarget^es? 】 ◎ If NewTarget is undefined, let newTarget be F, else let newTarget be NewTarget.
  3. %super := %F.`GetPrototypeOf^es() ◎ Let super be F.[[GetPrototypeOf]]().
  4. `ReturnIfAbrupt$A(%super) ◎ ReturnIfAbrupt(super).
  5. ~IF `IsConstructor$A(%super) ~EQ `false^v ~THEN ~THROW `TypeError^t ◎ If IsConstructor(super) is false, throw a TypeError exception.
  6. %O := `Construct$A(%super, «%message», %newTarget) ◎ Let O be Construct(super, «‍message», newTarget).
  7. ~IF %name ~NEQ `undefined^v : ◎ If name is not undefined, then

    1. %name := `ToString$A(%name) ◎ Let name be ToString(name).
    2. %status := `DefinePropertyOrThrow$A(%O, `name^l, `TFT-name^desc ) ◎ Let status be DefinePropertyOrThrow(O, "name", PropertyDescriptor{[[Value]]: name, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).
    3. `ReturnIfAbrupt$A(%status) ◎ ReturnIfAbrupt(status).
    4. %code := [ ~error名に対し`~error名~一覧$に旧来~codeが指示されていれば それ / ~ELSE_ `0^v ] ◎ Let code be the legacy code indicated in the error names table for error name name, or 0 if there is none.
    5. %status := `DefinePropertyOrThrow$A(%O, `code^l, `TFT-code^desc) ◎ Let status be DefinePropertyOrThrow(O, "code", PropertyDescriptor{[[Value]]: code, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).
    6. `ReturnIfAbrupt$A(%status) ◎ ReturnIfAbrupt(status).
  8. ~RET %O ◎ Return O.

4.11.2. DOMException 原型~obj

`DOMException 原型~obj$は、 `ErrorPrototype^ ( `ECMA-262$r 6.1.7.4 節)を値にとる `Prototype^es 内的~propを持た~MUST。 ◎ The DOMException prototype object MUST have an internal [[Prototype]] property whose value is %ErrorPrototype% ([ECMA-262], section 6.1.7.4).

`DOMException 原型~obj$の`~class文字列$は、 `DOMExceptionPrototype^l で~MUST。 ◎ The class string of the DOMException prototype object is “DOMExceptionPrototype”.

`DOMException 原型~obj$上には、次の特徴を有する~propが存在し~MUST:

  • 名前は `constructor^l
  • 値は `DOMException 構築子~obj$
◎ There MUST be a property named “constructor” on the DOMException prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the DOMException constructor object.

`~error名~一覧$に挙げられた どの旧来~codeに対しても, `DOMException 原型~obj$上に,次の特徴を有する~propが存在し~MUST:

  • その名前と値は、一覧に指示されている名前と値
  • 属性 `FTF^desc を持つ
◎ For every legacy code listed in the error names table, there MUST be a property on the DOMException prototype object whose name and value are as indicated in the table. The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

4.12. 例外~obj

`単純例外$は、対応する型の~native ~JS~objにより表現される。 ◎ Simple exceptions are represented by native ECMAScript objects of the corresponding type.

`DOMException$ は、 `DOMException 原型~obj$を継承する`~platform~obj$により表現される。 ◎ DOMExceptions are represented by platform objects that inherit from the DOMException prototype object.

~JS内で DOMException を表現している,どの~platform~objも、`初期~obj$と丁度~同じ様に大域環境に属する。 通常のように, あるいは `new^c 式の一部として,`DOMException 構築子~obj$の~callにより作成された例外~objが属する大域環境は、 `DOMException 構築子~obj$自身が属する大域環境と同じで~MUST。 ◎ Every platform object representing a DOMException in ECMAScript is associated with a global environment, just as the initial objects are. When an exception object is created by calling the DOMException constructor object, either normally or as part of a new expression, then the global environment of the newly created object is associated with MUST be the same as for the DOMException constructor object itself.

その `DOMException$ ~obj %O の `Prototype^es 内的~propの値は、 %O が属する大域環境に属する `DOMException 原型~obj$で~MUST。 ◎ The value of the internal [[Prototype]] property of a DOMException object MUST be the DOMException prototype object from the global environment the exception object is associated with.

`DOMException$ ~objの `~class文字列$は, `DOMException^l で~MUST。 ◎ The class string of a DOMException object MUST be “DOMException”.

DOMException ~objの意図は、[ `Object.prototype.toString^c に渡されたときに応答が異なることと, `code^l ~propを持つこと ]を除いて,~JS仕様が定義する他の種々の~native `Error^t ~objと同様になることである。 ~native `Error^t ~obj上に — 例えば~stack~traceや~error行番号などを公開するような — 非標準の~propを与える実装は、それらを例外~obj上にも公開しなければならないことになる。 ◎ The intention is for DOMException objects to be just like the other various native Error objects that the ECMAScript specification defines, apart from responding differently to being passed to Object.prototype.toString and it having a “code” property. If an implementation places non-standard properties on native Error objects, exposing for example stack traces or error line numbers, then these ought to be exposed on exception objects too.

4.13. 例外の作成と投出

最初に、 `現在の大域環境@ を,次の~algoを走らせた結果として定義する: ◎ First, we define the current global environment as the result of running the following algorithm:

  1. %F := ~JS~call~stack上の最上層の~callの中で `this^v 値に利用されている `Function^t ~obj — ここで, %F は次のいずれかの~IDL構成子に対応する:

    • `属性$
    • `演算$
    • `有index~prop$
    • `有名~prop$
    • `Constructor$x
    • `有名~構築子$
    • `文字列化子$
    ◎ Let F be the Function object used as the this value in the top-most call on the ECMAScript call stack where F corresponds to an IDL attribute, operation, indexed property, named property, constructor, named constructor or stringifier.
  2. ~RET %F に対応する~IDL構成子に応じて,次で与えられる`~ifc$ 【を表現する`~platform~obj$】 が属する大域環境 ◎ ↓

    属性
    演算
    文字列化子
    その定義が現れる~ifc ◎ If F corresponds to an attribute, operation or stringifier, then return the global environment associated with the interface that definition appears on.
    有index~prop
    有名~prop
    その~propの[ 取得子/設定子/削除子 ]が定義されている~ifc ◎ Otherwise, if F corresponds to an indexed or named property, then return the global environment associated with the interface that the indexed or named property getter, setter or deleter was defined on.
    有名~構築子
    `~ifc~obj$である構築子
    その構築子に対応する~ifc ◎ Otherwise, if F is a named constructor for an interface, or is an interface object for an interface that is a constructor, then return the global environment associated with that interface.
    例外~field取得子†
    その例外~fieldが定義されている例外 ◎ Otherwise, F is an exception field getter. Return the global environment associated with the exception on which the exception field was defined.
    【† この項は不要であろう(仕様の更新に伴う削除漏れ — 例外~field取得子は,過去版に定義されていたが、その記述は現在~削除されている)。 】

[ 名前 %N, ~UAにより定義される~message %M ]( %M は随意)を伴う,`単純例外$/ `DOMException$ %E を`作成する$ときは、次の手続きに従わ~MUST: ◎ When a simple exception or DOMException E is to be created, with error name N and optional user agent-defined message M, the following steps MUST be followed:

  1. %M := [ %M が指定されていないならば `undefined^v / ~ELSE_ %M を `String^t 値に`toES^した結果 ] ◎ If M was not specified, let M be undefined. Otherwise, let it be the result of converting M to a String value.
  2. %N := %N を `String^t 値に`toES^した結果 ◎ Let N be the result of converting N to a String value.
  3. %args := %E の型に応じて,次で与えられる~JS値の~list: ◎ Let args be a list of ECMAScript values.

    `DOMException$◎E is DOMException
    (`undefined^v, %N) ◎ args is (undefined, N).
    `単純例外$◎E is a simple exception
    (%M) ◎ args is (M)
  4. %G := `現在の大域環境$ ◎ Let G be the current global environment.
  5. %X := %E の型に応じて,次で与えられる~obj: ◎ Let X be an object determined based on the type of E:

    `DOMException$◎E is DOMException
    %G に属する, `DOMException 構築子~obj$ ◎ X is the DOMException constructor object from the global environment G.
    `単純例外$◎E is a simple exception
    %G に属する,対応する~JS~errorのための構築子 ◎ X is the constructor for the corresponding ECMAScript error from the global environment G.
  6. ~RET %args を引数~listとして, %X を関数として~callした結果 ◎ Let O be the result of calling X as a function with args as the argument list. ◎ Return O.

[ `~error名$ %N, ~UAにより定義される~message %M ]( %M は随意)を伴う, ~IDL `単純例外$/ `DOMException$ %E を`投出する$ときは、次の手続きに従わ~MUST: ◎ When a simple exception or DOMException E is to be thrown, with error name N and optional user agent-defined message M, the following steps MUST be followed:

  1. %O := [ `~error名$ %N, ~message %M ]を伴う,指定された例外 %E を`作成-$した結果 ◎ Let O be the result of creating the specified exception E with error name N and optional user agent-defined message M.
  2. %O を投出する ◎ Throw O.

上の~algoは、 例外を表現する~platform~obj が, `Function^t %F から[ %F が出自にする大域環境 ]の外へ伝播することを制約しない。 例えば、次の~IDLを考える: ◎ The above algorithms do not restrict platform objects representing exceptions propagating out of a Function to be ones that are associated with the global environment where that Function object originated. For example, consider the IDL:

interface A {

  // ( %x ) を引数に %m 上の `computeSquareRoot^M を~call
  double doComputation(MathUtils m, double x);
};

interface MathUtils {
  // %x が負ならば `NotSupportedError^t を投出。そうでなければ %x の平方根を返す。
  double computeSquareRoot(double x);
};

異なる大域環境に属する `MathUtils^T ~objを doComputation に渡した場合、投出される例外は,その大域環境に属する: ◎ If we pass a MathUtils object from a different global environment to doComputation, then the exception thrown will be from that global environment:

var a = getA();                      // この大域環境に属する~obj
var m = otherWindow.getMathUtils();  // 異なる大域環境に属する `MathUtils^T ~obj

a instanceof Object;                 // 
m instanceof Object;                 // 
m instanceof otherWindow.Object;     // 

try {
  a.doComputation(m, -1);
} catch (e) {
  e instanceof DOMException;          // 
  e instanceof otherWindow.DOMException;  // 
}

この文書が~JS組込みの `Error^t ~instanceの投出に課す,どの要件も、 `現在の大域環境$に属する組込みのものを利用し~MUST。 ◎ Any requirements in this document to throw an instance of an ECMAScript built-in Error MUST use the built-in from the current global environment.

4.14. 例外の取扱い

~JS言語束縛のどの~algoも, 処理~要件も、 ~JS例外を~catchしない。 ~JS `Function^t がこの節の要件により呼出され,その `Function^t が例外の投出により終了したときはいつでも、その例外は~call元まで(そこで~catchされない場合は更にその~call元まで,等々)伝播し~MUST。 ◎ None of the algorithms or processing requirements in the ECMAScript language binding catch ECMAScript exceptions. Whenever an ECMAScript Function is invoked due to requirements in this section and that Function ends due to an exception being thrown, that exception MUST propagate to the caller, and if not caught there, to its caller, and so on.

次の`~IDL片$は2つの`~ifc$と1つの`例外$を定義する。 `ExceptionThrower^T 上の `valueOf^M 属性は、その値の取得-が試みられたときに常に例外を投出するように定義されている。 ◎ The following IDL fragment defines two interfaces and an exception. The valueOf attribute on ExceptionThrower is defined to throw an exception whenever an attempt is made to get its value.

interface Dahut {
  attribute DOMString type;
};

interface ExceptionThrower {
  // この属性は常に `NotSupportedError^t を投出し,決して値を返さない。
  attribute long valueOf;
};

~JS実装がこの~ifcを~supportしているとするとき、例外は次の~codeに従って取扱われる: ◎ Assuming an ECMAScript implementation supporting this interface, the following code demonstrates how exceptions are handled:

var d = getDahut();              // `Dahut^T の~instanceを得る。
var et = getExceptionThrower();  // `ExceptionThrower^T の~instanceを得る。

try {
  d.type = { toString: function() { throw "abc"; } };
} catch (e) {
  /* 文字列 `abc^l はここで~catchされる。何故なら、~native~objから
   文字列への変換の一環として匿名~関数が呼出され,
   `DefaultValue^es, ToPrimitive, ToString のいずれの~algoも,
   例外を~catchするように定義されていないので。 */
}

try {
  d.type = { toString: { } };
} catch (e) {
  /* 例外はここで~catchされる。 toString ~propの値である
   ~native~obj上で `Call^es の呼出しが試みられるので。 */
}

d.type = et;
  /* ~catchされなかった `NotSupportedError^t `DOMException$ は ここで投出される。
   `DefaultValue^es ~algoは, `ExceptionThrower^T ~obj上の
   `valueOf^l ~propの値の取得-を試みるので。
   例外はこの~code~blockの外へ伝播する。 */

5. 共通の定義

この節では、すべての`適合~実装$が~supportし~MUST,いくつかの共通の定義を指定する。 ◎ This section specifies some common definitions that all conforming implementations MUST support.

5.1. ArrayBufferView

typedef (Int8Array or Int16Array or Int32Array or
         Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
         Float32Array or Float64Array or DataView) `ArrayBufferView@;

`ArrayBufferView^T ~typedefは、 `ArrayBuffer$T 上の~viewを提供する~objを表現するために利用される。 ◎ The ArrayBufferView typedef is used to represent objects that provide a view on to an ArrayBuffer.

5.2. BufferSource

typedef (ArrayBufferView or ArrayBuffer) `BufferSource@;

`BufferSource^T ~typedefは、 `ArrayBuffer$T ~obj自身, または `ArrayBuffer$T 上の~viewを提供する~objを表現するために利用される。 ◎ The BufferSource typedef is used to represent objects that are either themselves an ArrayBuffer or which provide a view on to an ArrayBuffer.

5.3. DOMTimeStamp

typedef unsigned long long `DOMTimeStamp@;

`DOMTimeStamp^T 型は、ミリ秒数を表現するために利用される。 (何らかの起点に相対的な)絶対的な時間として,または相対的な時間差として。 この型を利用する仕様は、ミリ秒数の解釈され方も定義する必要がある。 ◎ The DOMTimeStamp type is used for representing a number of milliseconds, either as an absolute time (relative to some epoch) or as a relative amount of time. Specifications that use this type will need to define how the number of milliseconds is to be interpreted.

5.4. Function

callback `Function@ = any (any... arguments);

`Function^T `呼戻~関数$型は、渡される引数や返値の種類に制約のない関数~値を表現するために利用される。 ◎ The Function callback function type is used for representing function values with no restriction on what arguments are passed to it or what kind of value is returned from it.

5.5. VoidFunction

callback `VoidFunction@ = void ();

`VoidFunction^T `呼戻~関数$型は 引数をとらず, 値を返さない関数~値を表現するために利用される。 ◎ The VoidFunction callback function type is used for representing function values that take no arguments and do not return any value.

6. 拡張性

~INFORMATIVE

言語束縛の要件に対する拡張は、この文書~内で定義される拡張属性と競合しない`拡張属性$を利用して指定できる。 [ 私的な~project特有の利用 ]のための拡張は、他の仕様に現れる`~IDL片$に含められるべきではない。 他の仕様の用途に要求される拡張は、この文書の将来~versionに取り込まれるためには, Web IDL の担当グループ(この文書が書かれた時点では W3C Web Platform Working Group )による~~調整を通すことが推奨される。 ◎ Extensions to language binding requirements can be specified using extended attributes that do not conflict with those defined in this document. Extensions for private, project-specific use should not be included in IDL fragments appearing in other specifications. It is recommended that extensions that are required for use in other specifications be coordinated with the group responsible for work on Web IDL, which at the time of writing is the W3C Web Platform Working Group, for possible inclusion in a future version of this document.

~IDL言語の他の側面の拡張は極力~避けられるべきである。 ◎ Extensions to any other aspect of the IDL language are strongly discouraged.

7. この仕様を参照するとき

~INFORMATIVE

一つ以上の`~IDL片$を利用して Web ~platform~ifcを定義する他の仕様は、この仕様を参照することになるものと期待されている。 それらの仕様には、~IDLが この仕様の記述に従って解釈されることを指示する,次の様な~~文を含ませることを勧める: ◎ It is expected that other specifications that define Web platform interfaces using one or more IDL fragments will reference this specification. It is suggested that those specifications include a sentence such as the following, to indicate that the IDL is to be interpreted as described in this specification:

この仕様の付録 A の中の~IDL片は、この仕様が規範とする参照文献にて定義される~IDL片とともに,[ “Web IDL” 仕様に述べられる, 適合~IDL片の集合 に課される要件 ]に従って、解釈され~MUST。 [WEBIDL] ◎ The IDL fragment in Appendix A of this specification must, in conjunction with the IDL fragments defined in this specification's normative references, be interpreted as required for conforming sets of IDL fragments, as described in the “Web IDL” specification. [WEBIDL]

加えて、この仕様を参照する仕様における,~UAのための適合性クラスは、この仕様の `適合~実装$クラスを参照することを勧める: ◎ In addition, it is suggested that the conformance class for user agents in referencing specifications be linked to the conforming implementation class from this specification:

適合 FooML ~UAは、 “Web IDL” 仕様の記述に則り,この仕様の付録 A に示されている~IDL片に対しても 適合~実装 で~MUST。 [WEBIDL] ◎ A conforming FooML user agent must also be a conforming implementation of the IDL fragment in Appendix A of this specification, as described in the “Web IDL” specification. [WEBIDL]

8. 謝辞

~INFORMATIVE

編集者は、この仕様に~~寄与された,次の方々に感謝する:

The editor would like to thank the following people for contributing to this specification: Glenn Adams, David Andersson, L. David Baron, Art Barstow, Nils Barth, Robin Berjon, David Bruant, Jan-Ivar Bruaroey, Marcos Cáceres, Giovanni Campagna, Domenic Denicola, Michael Dyck, Brendan Eich, João Eiras, Gorm Haug Eriksen, Sigbjorn Finne, David Flanagan, Aryeh Gregor, Dimitry Golubovsky, James Graham, Aryeh Gregor, Kartikaya Gupta, Marcin Hanclik, Jed Hartman, Stefan Haustein, Dominique Hazaël-Massieux, Ian Hickson, Björn Höhrmann, Kyle Huey, Lachlan Hunt, Oliver Hunt, Jim Jewett, Wolfgang Keller, Anne van Kesteren, Olav Junker Kjær, Magnus Kristiansen, Takeshi Kurosawa, Yves Lafon, Travis Leithead, Jim Ley, Kevin Lindsey, Jens Lindström, Peter Linss, 呂康豪 (Kang-Hao Lu), Kyle Machulis, Mark Miller, Ms2ger, Andrew Oakley, 岡坂 史紀 (Shiki Okasaka), Jason Orendorff, Olli Pettay, Simon Pieters, Andrei Popescu, François Remy, Tim Renouf, Alex Russell, Takashi Sakamoto, Doug Schepers, Jonas Sicking, Garrett Smith, Geoffrey Sneddon, Jungkee Song, Josh Soref, Maciej Stachowiak, Anton Tayanovskyy, Peter Van der Beken, Jeff Walden, Allen Wirfs-Brock, Jeffrey Yasskin and Collin Xu.

編集者が休みの間、この文書を維持されていた Sam Weinig に特別な謝意を。 ◎ Special thanks also go to Sam Weinig for maintaining this document while the editor was unavailable to do so.

A. ~IDL文法

この節では、開始~記号 `Definitions$g が`~IDL片$全体に合致する, LL(1) 文法を定義する。 ◎ This section defines an LL(1) grammar whose start symbol, Definitions, matches an entire IDL fragment.

文法~内の各~生成規則は、その右側に,1個~以上の 終端/非~終端 記号の並び, または[ 記号なしを指示する epsilon ( ε ) ]を持つ。 大文字から始まる記号は,非~終端~記号であり、引用符で括られた記号は,引用符~内の~textに正確に合致する終端~記号である。 小文字から始まる記号は次の様な正規表現に合致する終端~記号である (Perl 5 の正規表現~構文 `PERLRE$r を利用): ◎ Each production in the grammar has on its right hand side either a non-zero sequence of terminal and non-terminal symbols, or an epsilon (ε) which indicates no symbols. Symbols that begin with an uppercase letter are non-terminal symbols. Symbols within quotes are terminal symbols that are matched with the exact text between the quotes. Symbols that begin with a lowercase letter are terminal symbols that are matched by the regular expressions (using Perl 5 regular expression syntax [PERLRE]) as follows:

`integer^g
-?([1-9][0-9]*|0[Xx][0-9A-Fa-f]+|0[0-7]*)
`float^g
-?(([0-9]+\.[0-9]*|[0-9]*\.[0-9]+)([Ee][+-]?[0-9]+)?|[0-9]+[Ee][+-]?[0-9]+)
`identifier^g
_?[A-Za-z][0-9A-Z_a-z-]*
`string^g
"[^"]*"
`whitespace^g
[\t\n\r ]+
`comment^g
\/\/.*|\/\*(.|\n)*?\*\/
`other^g
[^\t\n\r 0-9A-Za-z]

~tok化は Unicode 文字~並び `UNICODE$r に対し演算する。 ~tok化の際には、最長合致が利用され~MUST。 例えば,入力~textが “a1” であるなら、それは1個の `identifier$g に~tok化され, `identifier$g と `integer$g には分離されない。 最長合致が[ 上に挙げた,名前を持つ終端~記号の いずれか ]と[ 文法~内の,引用符で括られた終端~記号 ]のいずれにも合致し得る場合、後者の終端~記号に~tok化され~MUST。 したがって、入力~text “long” は, `identifier$g `long^l ではなく,引用符で括られた終端~記号 `long^sym として~tok化され、 “.” は, `other$g ではなく,引用符で括られた終端~記号 `.^sym として~tok化される。 ◎ The tokenizer operates on a sequence of Unicode characters [UNICODE]. When tokenizing, the longest possible match MUST be used. For example, if the input text is “a1”, it is tokenized as a single identifier, and not as a separate identifier and integer. If the longest possible match could match one of the above named terminal symbols or one of the quoted terminal symbols from the grammar, it MUST be tokenized as the quoted terminal symbol. Thus, the input text “long” is tokenized as the quoted terminal symbol "long" rather than an identifier called “long”, and “.” is tokenized as the quoted terminal symbol "." rather than an other.

~IDL構文においては、文字の大小は,文法~内で利用される引用符で括られた終端~記号と `identifier$g 終端~記号に利用される値の,いずれにおいても区別される。 したがって、例えば入力~text “Const” は,引用符で括られた終端~記号 `const^sym ではなく `identifier$g として~tok化され、 `識別子$ `A^l を伴う`~ifc$は, `a^l を伴うそれとは異なるものになり、 また,`拡張属性$ `constructor^x が `Constructor$x 拡張属性に認識されることはない。 ◎ The IDL syntax is case sensitive, both for the quoted terminal symbols used in the grammar and the values used for identifier terminals. Thus, for example, the input text “Const” is tokenized as an identifier rather than the quoted terminal symbol "const", an interface with identifier “A” is distinct from one named “a”, and an extended attribute [constructor] will not be recognized as the [Constructor] extended attribute.

`whitespace$g や `comment$g からなる任意~個数の終端~記号が、構文解析される入力~textにおける,他のどの終端~記号の合間にも、暗黙的に許容される。 それらの `whitespace$g や `comment$g は、構文解析~時には無視される。 ◎ Implicitly, any number of whitespace and comment terminals are allowed between every other terminal in the input text being parsed. Such whitespace and comment terminals are ignored while parsing.

次の LL(1) 文法の開始~記号 `Definitions$g が`~IDL片$に合致する: ◎ The following LL(1) grammar, starting with Definitions, matches an IDL fragment:

【 見出しをクリックするとその文法~記号の~~参照元が示される(上の終端~記号の表も同様)。 】

非~終端~記号 `Other$g は、 `(^sym, `)^sym, `[^sym, `]^sym, `{^sym, `}^sym, `,^sym を除く,任意の1個の終端~記号に合致する。 ◎ The Other non-terminal matches any single terminal symbol except for "(", ")", "[", "]", "{", "}" and ",".

非~終端~記号 `ExtendedAttribute$g は,任意の空でない終端~記号の並びに合致するが(丸括弧, 角括弧, 波括弧が対になっていて, かつ `,^sym ~tokがそれらの括弧対の間にのみ現れる限り)、それらの可能な並びのうち一部のみが この仕様で定義される`拡張属性$に利用される — これらの拡張属性に利用される構文については `idl-extended-attributes$sec に。 ◎ While the ExtendedAttribute non-terminal matches any non-empty sequence of terminal symbols (as long as any parentheses, square brackets or braces are balanced, and the "," token appears only within those balanced brackets), only a subset of those possible sequences are used by the extended attributes defined in this specification — see section 3.11 for the syntaxes that are used by these extended attributes.

B. 参照文献

B.1. 文献(規範的)

[ECMA-262]
ECMAScript Language Specification. Ecma International.
~ES6
[IEEE-754]
IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985). Institute of Electrical and Electronics Engineers, 1985.
[PERLRE]
Perl regular expressions (Perl 5.8.8). The Perl Foundation, February 2006.
http://www.perl.com/doc/manual/html/pod/perlre.html
日本語訳
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997.
http://tools.ietf.org/html/rfc2119
[RFC2781]
UTF-16, an encoding of ISO 10646, P. Hoffmann and F. Yergeau. IETF, February 2000.
http://tools.ietf.org/html/rfc2781
[RFC3629]
UTF-8, a transformation format of ISO 10646, F. Yergeau. IETF, November 2003.
http://tools.ietf.org/html/rfc3629
[SECURE-CONTEXTS]
Secure Contexts. M. West and Y. Zhu, Editors. World Wide Web Consortium, October 2015.
https://w3c.github.io/webappsec-secure-contexts/
[TYPEDARRAYS]
Typed Array Specification, V. Vukicevic and K. Russell, eds. The Khronos Group, 08 February 2011.
https://www.khronos.org/registry/typedarray/specs/1.0/
[UNICODE]
The Unicode Standard, Version 6.0 or later. The Unicode Consortium. Mountain View, California, 2011. ISBN 978-1-936213-01-6.
http://www.unicode.org/versions/Unicode6.0.0/

B.2. 文献(参考)

[DOM]
DOM Standard. A. van Kesteren, A. Gregor and Ms2ger, Editors. WHATWG, 22 July 2013.
https://dom.spec.whatwg.org/
[DOM3CORE]
Document Object Model (DOM) Level 3 Core Specification. A. Le Hors, et al., Editors. World Wide Web Consortium, April 2004.
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/
[HTML5]
HTML5. I. Hickson, Editor. World Wide Web Consortium, May 2011.
http://www.w3.org/TR/2011/WD-html5-20110525/
[HTML]
HTML, I. Hickson, Editor. WHATWG, 30 July 2013.
https://html.spec.whatwg.org/multipage/
[OMGIDL]
CORBA 3.1 – OMG IDL Syntax and Semantics chapter. Object Management Group, January 2008.
http://www.omg.org/cgi-bin/doc?formal/08-01-04.pdf
[WEBIDL-JAVA]
Java langage binding for Web IDL. World Wide Consortium, work in progress.
http://dev.w3.org/2006/webapi/WebIDL/java.html
[XMLNS]
Namespaces in XML 1.0 (Third Edition), T. Bray, D. Hollander, A. Layman, R. Tobin, H. Thompson, eds. World Wide Web Consortium, 8 December 2009.
http://www.w3.org/TR/2009/REC-xml-names-20091208/

C. 変更点

~INFORMATIVE

この文書の各~発行における主要な変更点を(最近のものから順に)以下に挙げる。 第1版の開発時における変更点については、その仕様の 変更点の節 を~~参照のこと。 ◎ The following is a list of substantial changes to the document on each publication. For the list of changes during the development of the First Edition of this specification, see that document's Changes appendix.

現在の編集者草案:

  • ES ~obj値を~IDL連列~型と辞書~型を包含している共用体に変換するときは、多重定義~解決と同様に,連列~型が先んじるように修正した。 ◎ Fixed unions containing a sequence and a dictionary to try the sequence first when given an object, just like overload resolution does.
  • 辞書~上での `Constructor$x 拡張属性の~supportを除去した。 ◎ Removed support for [Constructor] on dictionaries.
  • `LenientSetter$x 拡張属性を追加した。 ◎ Added the [LenientSetter] extended attribute.
  • `SecureContext$x 拡張属性を追加した。 ◎ Added the [SecureContext] extended attribute.
  • ES6 に合わせるため、 `Unscopeable^x 拡張属性の名称を `Unscopable$x に変更した。 ◎ Changed from [Unscopeable] to [Unscopable] to match ES6 better.
  • 用語 “列挙不可( unenumerable )” とそれに関わる注釈文を除去して、拡張属性 `LegacyUnenumerableNamedProperties$x に置換した。 ◎ Removed the term "unenumerable" and its associated prose and replaced it by the extended attribute [LegacyUnenumerableNamedProperties].
  • 他の仕様が~objの内的~methを上書きすることを許容した。 ◎ Allowed object internal methods to be overridden by other specifications.
  • `保安~検査を遂行する$~hookに~parameterを追加した。 ◎ Added some more parameters to the “perform a security check” hook.
  • すべての `Function^t ~objに対し、 `name^l ~propを定義した(演算, および属性の取得子と設定子に対するそれも含めて)。 ◎ Defined the “name” property for all Function objects (including those for operations and attribute getters and setters).
  • `Date^T 型を除去した。 ◎ Removed the Date type.
  • `定数$の識別子に対する `length^l, `name^l の利用を不許可にした。 ◎ Disallowed “length” and “name” from being used as identifiers of constants.
  • `FrozenArray_T^ 型を追加した。 ◎ Added a FrozenArray<T> type.
  • `ArrayClass^x を `LegacyArrayClass$x に改称した。 ◎ Renamed [ArrayClass] to [LegacyArrayClass].
  • `~varT[]^T 配列~型を除去した。 ◎ Removed T[] array types.
  • `NewObject^x を,~promise型を返すものにも許容した。 ◎ Allowed [NewObject] to be used on things with a promise type.
  • ~maplike/~setlike が誤った~objに演算していた,種々の事例を修正した。 ◎ Fix various cases in which maplike/setlike were operating on the wrong objects.
  • ~ifcの[ 広義~帰結~ifc, 被継承~ifc ]の中に,複数の[ ~maplike, ~setlike, 可反復 ]宣言が現れるのを不許可にした。 また、[ ~maplike/~setlike/可反復 ]が宣言された~ifcの[ 広義~帰結~ifc, 被継承~ifc ]についても,関連の制約される~mb名( `entries^l, `values^l など)を不許可にした。 ◎ Disallow maplike, setlike and iterable declarations from appearing more than once on an interface and its inherited and consequential interfaces. Also disallow the relevant restricted member names (such as “entries” and “values”) on the inherited and consequential interfaces.
  • `stringifier^c を伴う属性には、 `USVString$T 型も許容されるようにした。 ◎ Allowed stringifier attributes to have type USVString.
  • ES6 に合致するよう、[ ~ifc~obj, 有名~構築子, 辞書~構築子 ]に `name^l ~propを追加した。 ◎ Gave interface objects, named constructors, and dictionary constructors a "name" property to match ES6.
  • 辞書~構築子~上の `length^l ~propを,~configurableにした。 ◎ Made the "length" property on dictionary constructors configurable.
  • `ArrayBuffer$T, `DataView$T, 有型~配列~objに対する型を追加した。 ◎ Added types for ArrayBuffer, DataView and typed array objects.
  • `USVString^T を追加するとともに、 ~IDLにおける文字列~literalは,すべての[ 文字列~型の[ 随意~引数, 辞書~mb 既定~値 ]]に値を与えるために利用できるようにした。 ◎ Added USVString and allowed string literals in IDL to be used to give values for all string-typed optional argument and dictionary member default values.
  • 連列を[ 辞書, 呼戻~関数, すべての~ifc型 ]から判別可能にした。 ◎ Made sequences distinguishable from dictionaries, callback functions, and all interface types.
  • ~IDL例外を除去し, `DOMException$T を焼き込んだ。 `Error^t および `DOMException$T を型として追加した。 ◎ Removed IDL exceptions, baked in DOMException, and added Error and DOMException as types.
  • `MapLike^x を除去して, `可反復~宣言$, `~maplike 宣言$, `~setlike 宣言$ を追加した。 ◎ Removed [MapLike] and added iterable, maplike and setlike declarations.
  • 独自の `Object.prototype.toString^c 定義を除去し,代わりに `~class文字列$が ~obj上の `toStringTag_symbol^ ~propに波及するように定義した。 ◎ Removed the custom Object.prototype.toString definition and instead defined class strings to influence the @@toStringTag property on objects.
  • `Unscopable^x 拡張属性を追加した。 ◎ Added the [Unscopable] extended attribute.
  • ES 値から~IDL連列~値への変換を,どの可反復も連列に変換し得るように書き換えた。 ◎ Rewrote ES to IDL sequence conversion so that any iterable is convertible to a sequence.
  • `promise_T^ 型のための文法~生成規則を追加し, `void$T も %T に許容した。 ◎ Added grammar production for Promise<T> types and allowed T to be void.
  • `Map^t 構築子と同じように挙動する, “可反復から~objを初期化する” ための定義を追加した。 ◎ Added a definition to "initialize an object from an iterable", which behaves like the Map constructor.
  • 連列~型の演算~引数や辞書~mbの既定~値に利用できる `[]^c を追加した。 ◎ Added a default value [] that can be used for sequence-typed operation argument default values and dictionary member default values.
  • ~promise型を追加した。 ◎ Added promise types.
  • `NewObject^x, `SameObject^x 拡張属性を追加した。 ◎ Added the [NewObject] and [SameObject] extended attributes.
  • 辞書に対する `Constructor^x の指定を可能にした。 ◎ Allowed [Constructor] to be specified on dictionaries.
  • `RegExp^t 型を追加した。 ◎ Added a RegExp type.
  • ~ifc上で宣言し得る反復子を追加した。 ◎ Added iterators that can be declared on interfaces.
  • 有index~propを伴う~objに `iterator_symbol^ ~propを追加した。 ◎ Added an @@iterator method to objects with indexed properties.
  • ECMAScript 6th Edition に更新した。 ◎ Updated to ECMAScript 6th Edition.
  • 直列化子を追加した。 ◎ Added serializers.
  • ~JS `String^t 値として特定0の符号化方式を伴わない 8 ~bit文字列を表現するための, `ByteString^t 型を追加した。 ◎ Added a ByteString type, for representing 8 bit strings without a particular encoding as ECMAScript String values.
  • 静的~属性を追加した。 ◎ Added static attributes.
  • ~ifcは、それが継承する~ifcが大域環境に`公開され$ないならば,自身もまた`公開され$ないことを明らかに。 ◎ Make it clear that an interface can't be exposed in a global where its parent interface is not exposed.
  • 尾部に位置する辞書~型の演算~引数は、辞書~型が必須~辞書~mbを持たない場合には,随意にできるようにした。 ◎ Allow dictionary-typed trailing-position operation arguments not to be optional, if and only if the dictionary type has a required dictionary member.
  • 有名/有index 設定子をより良く取扱えるようにするため、~platform~obj `Set^es 内的~methを追加した。 ◎ Added a platform object [[Set]] internal method to handle named and indexed setters better.
  • 作成子の概念を除去した — 設定子が常に作成子でもある。 ◎ Removed the concept of creators; setters are always also creators.
  • `NoInterfaceObject^x を伴わない~ifcによる `NoInterfaceObject^x ~ifcの継承ingを不許可にした。 ◎ Disallowed an interface without [NoInterfaceObject] inheriting from a [NoInterfaceObject] interface.
  • 有index~prop削除子を除去した。 ◎ Removed indexed deleters.
  • [[ 継承階層の根元でない~ifc ]の~ifc~obj ]の原型は,その先祖~ifcの~ifc~objにした。 ◎ Made the prototype of an interface object of a non-root interface be the interface object of its ancestor interface.
  • 非~呼戻~ifc~objの `prototype^l ~propの~prop属性を明確化した。 ◎ Clarified the property attributes of the "prototype" property of non-callback interface objects.
  • ~ifc~obj/有名~構築子 上の `length^l ~propを,~configurableにした。 ◎ Made the "length" property on interface objects and named constructors configurable.
  • 辞書~mbを必須にする仕方を追加した。 ◎ Added a way to mark dictionary members as required.
  • 識別子の最初の文字の後には,~hyphenも許容した。 ◎ Allowed hyphens in identifiers after the first character.
  • `Exposed^x についての言及を[ ~ifc上の~mbに対する値には,その~ifc上の値が(もしあれば)既定で利用される ]ことを明らかにするよう修正した。 ◎ Fix [Exposed] text to make it clear that the value on the interface, if any, is used as the value for its members by default.
  • `Exposed^x など,識別子~listを引数にとる拡張属性の文法を修正した。 ◎ Fixed the grammar for extended attributes that take an identifier list, such as [Exposed].
  • [[Enumerable]] が `false^v にされた~propを公開できるようにするための語 “列挙不可” を追加した。 ◎ Add a term "unenumerable" to allow named properties to be exposed as properties with [[Enumerable]] set to false.
  • `Exposed^x, `PrimaryGlobal^x 拡張属性を追加した。 それに伴い, `Global^x に識別子を利用できるようにした。 ◎ Added the [Exposed] and [PrimaryGlobal] extended attributes and allowed an identifier to be used with [Global].
  • `TreatUndefinedAs^x を削除した。 ◎ Removed [TreatUndefinedAs].
  • `TreatNonCallableAsNull^x を `TreatNonObjectAsNull^x に改称した上で、その意味論を,任意の~objが許容されるように変更した。 `TreatNonObjectAsNull^x の場合に生じ得るようになった[ ~objが~callableでないときの,呼戻~関数の呼出 ]に際しては、何もしないものとするよう,変更した。 ◎ Renamed [TreatNonCallableAsNull] to [TreatNonObjectAsNull] and changed its semantics to allow any object. Changed callback function invocation to be a no-op when the object is not callable, which can now happen in the [TreatNonObjectAsNull] case.
  • 呼戻に対する既定の `this^v 値を `null^v から `undefined^v に変更した。 ◎ Changed the default this value for callbacks from null to undefined.
  • 有名~prop~objが関数~objでなければならない要件を削除した。 ◎ Removed the requirement for named properties objects to be function objects.
  • 有名~prop~obj上における~propの定義を不許可にした。 ◎ Disallowed properties from being defined on a named properties object.
  • 有名~propの可視性判定~algoの無限~loopを修正した。 ◎ Fixed infinite loop in named property visibility algorithm.
  • 文字列化子と直列化子は、属性や演算に委譲される挙動において, `Get^es や `Call^es を利用しないようにした。 ◎ Made stringifiers and serializers not use [[Get]] or [[Call]] for the their attribute or operation delegated behavior.
  • enum ~listの末尾に,余分な~commaを許容した。 ◎ Allowed trailing optional comma in enum lists.
  • 呼戻~ifc上に定義される静的~ifc~mbは、不許可にした。 ◎ Disallowed static interface members from being defined on a callback interface.
  • 演算の呼出し/属性に対する~accessの際に,保安~検査のための hook を追加した。 ◎ Added a hook to do a security check when invoking an operation or accessing an attribute.
  • 呼戻が~incumbent~scriptに対しどのように波及するかを定義した。 ◎ Defined how callbacks influence the incumbent script.
  • ~~省略された随意~引数~supportするため,呼戻~関数の呼出され方を変更した。 ◎ Changed how callback functions are invoked to support missing optional arguments.
  • `NamedPropertiesObject^x を `Global^x に改称した。 それは今や、~ifc~mbに対する~propが~ifc原型~objではなく,~obj自身の上に現れるようにする。 ◎ Renamed [NamedPropertiesObject] to [Global], which now also causes properties for interface members to appear on the object itself rather than on the interface prototype object.
  • 他の primitive 型から `boolean$T を~~分離した。 [ `boolean$T, `実数~型$, `DOMString$T ]を,判別可能にした。 ◎ Split out boolean from the other primitive types. Made boolean, numeric types and DOMString distinguishable.
  • 設定子, 作成子, 削除子 のいずれかを持つ~ifcには,取得子が在することを要求した。 ◎ Required a getter to be present on an interface if it has a setter, creator or delete.
  • `Unforgeable^x を,[ 演算/~ifc ]にも適用されるように拡張した。 ◎ Extended [Unforgeable] to apply to operations and interfaces.
  • すべての演算~引数は随意として指定できるようにされ、 `undefined^v 引数~値は、~~省略された随意~引数~値として扱われるように,挙動を元に戻した。 有効~多重定義~集合と多重定義~解決~algoにはこれが織り込まれると同時に, 判別引数~indexには `undefined^v 値も渡せるようになり,その~indexに位置する随意~引数を伴う多重定義が選定されるようにした。 同時に `TreatUndefinedAs=Missing^x も削除した。 ◎ Allowed all operation arguments to be specified as being optional and changed back to the behavior of undefined being treated as a missing optional argument value. Modified the effective overload set and overload resolution algorithms to take this into account, as well as allowing an undefined value passed as the argument value at the distinguishing index to select the overload with an optional argument at that index. Also removed [TreatUndefinedAs=Missing].
  • ~JS値から~IDL辞書への変換~algoを,値 `undefined^v を伴う~propは存在しないものとして扱うように変更した。 ◎ Changed the ECMAScript to IDL dictionary conversion algorithm to treat a property with the value undefined as missing.
  • `typedef^c ~keywordの後に拡張属性を与えられる能を削除した。 その特色機能は利用されていないので。 ◎ Removed the ability to put extended attributes after the typedef keyword, as that feature is unused.
  • `long long$T, `unsigned long long$T の変換~algoを、連続的な範囲を正しく特定して, `Number^t から得られる整数が一意に表現されるように修正した。 ◎ Fixed the long long and unsigned long long conversion algorithms to correctly identify the range of contiguous, exactly, uniquely representable integers you can get from a Number.
  • ~implements文を利用して mixed in された 演算, 属性~取得子, 属性~設定子に対する `Function^t ~objが各~ifcごとに異なるものであり、それぞれの `Function^t の複製が[ その `Function^t ~objを~ifc原型~obj上に持つ~ifc ]を実装する~obj上でのみ働くことについて、明確化した。 ◎ Clarified that Function objects for operations and attribute getters and setters are distinct on each interface they are mixed in to using an implements statement, and that each copy of the Function works only on objects that implement the interface whose interface prototype object the Function object is on.
  • 初期~objの~list内の有名~prop~objに言及した。 ◎ Mention the named properties object in the list of initial objects.
  • 他の window からの~objがそれらの instanceof であるものと見なされるようにするため ~ifc~obj上の custom `HasInstance^es を復活した。 ◎ Added back a custom [[HasInstance]] on interface objects to allow objects from other windows to be considered instanceof them.
  • `unrestricted double$T に対する変換~algoを利用して `Number^t 値から `any$T への変換を修正した。 ◎ Fixed conversion of Number values to any by using the conversion algorithm for unrestricted double.
  • 定数と静的~演算を除くどの構成子の識別子にも `prototype^l を許容した。 ◎ Allowed an identifier to be “prototype” for any construct except constants and static operations.
  • 利用者~obj定義における、呼戻~ifcが複数の演算を持っているときでも `Call^es 内的~methが演算の実装として扱われる~bugを修正した。 ◎ Fixed a bug in the user object definition where the internal [[Call]] method would be treated as the implementation of an operation even if the callback interface had more than one operation.
  • 一貫性のため、多重定義~解決~algoと共用体~型の変換~algoを~~調整した。 ◎ Further tweaked the overload resolution algorithm and union type conversion algorithm for consistency.
  • ~IDL属性 における `Unforgeable$x の出現について、その属性が宣言されている~ifcを別の~ifcが継承している場合の制約を解禁しつつ、継承している~ifcは同じ識別子を持つ属性を持たないものとする要件を追加した。 ◎ Lifted the restriction on [Unforgeable] appearing on an IDL attribute if another interface inherits from the one the attribute is declared on, but required that the inheriting interface not have an attribute with the same identifier.
  • 属性~設定子に引数が渡されなかった場合に `undefined^v と見なす代わりに例外を投出するようにした。 ◎ Made attribute setters throw if no argument was passed to them, instead of assuming undefined.
  • 辞書は自身を参照できないようにした。 ◎ Prevented dictionaries from referencing themselves.
  • `Array^t でない~JS~obj から連列~型や配列~型への変換を許容するため、連列, 配列, 辞書 は再び判別可能でないものとした。 ◎ Made sequences, arrays and dictionaries undistingishable again, thereby allowing non-Array ECMAScript objects to be converted to sequence and array types.
  • 例外を投出する際のその各種~field値についての要件を追加した。 ◎ Added a requirement to state what the values of an exception’s fields are when throwing it.
  • ~IDL演算 に対する Function ~obj上の `length^l ~propを,要求されている引数の最小の個数を返すように,変更した。 ◎ Changed the “length” property on Function objects for IDL operations to return the smallest number of required arguments.
  • 辞書が演算~引数や辞書~mbの型に利用されている場合は~nullableになれないことを明確化した。 ◎ Clarified that dictionaries may not be nullable when used as the type of an operation argument or dictionary member.
  • 構築子を持たない~ifc~obj上の `length^l ~propの値を指定した。 ◎ Specify the value of the “length” property on interface objects that do not have constructors.
  • ~objが有indexおよび有名~propのいずれも~supportする場合に配列~index~propを 有名~propとして扱わないように。 ◎ Do not treat array index properties as named properties if an object supports both indexed and named properties.
  • 随意~引数が後続するような,辞書~型の引数も随意とすることを必須化し、その種の随意~引数は,既定~値として常に空の辞書を持つと見なされることに。 また、辞書~型は、~nullable型の内側での利用は不許可にされ, ~nullable型とも判別可能でなくした。 ◎ Require that dictionary type arguments followed by optional arguments must also be optional, and that such optional arguments always are assumed to have a default value of an empty dictionary. Also disallow dictionary types from being used inside nullable types and from being considered distinguishable from nullable types.
  • 辞書~mbには常に既定~値が在するものと見なされる。 ◎ Always consider dictionary members with default values as present.
  • 明確性のため, `Clamp^x ~algoを~~調整した。 ◎ Tweak [Clamp] algorithms for clarity.
  • 例外~objが `Class^es “Error” を持つことを要求した。 それらが~native Error ~objと同様の非標準~propを持つことに言及した。 ◎ Require exception objects to have [[Class]] “Error” and suggest that they have any non-standard properties that native Error objects do.
  • whitespace ~tokの正規表現の誤りを修正した。 ◎ Fixed a bug in the whitespace token regular expression.
  • 属性や例外~fieldの型として,共用体~型の内側における辞書の利用を明示的に不許可にした。 ◎ Explicitly disallow dictionaries from being used inside union types as the type of an attribute or exception field.
  • 判別可能の定義における、~nullable共用体~型と, ~nullable~mb型を持つ非~nullable共用体~型とが判別可能であった誤りを修正した。 ◎ Fixed a bug in the definition of distinguishability where a nullable union type and a non-nullable union type that has a nullable member type were considered distinguishable.
  • ~implements文における呼戻~ifcの利用を不許可にした。 ◎ Disallowed callback interfaces from being used in implements statements.
  • “例外~型” を “例外~名” に改称した。 ◎ Renamed “exception types” to “exception names”.
  • 非~呼戻 ~ifcに対し呼戻~ifcからの継承ingを不許可にした。 ◎ Disallowed non-callback interfaces from inheriting from callback interfaces.
  • 有index~propを伴う~platform~objから連列~型への変換のための~algoを、存在すら不確かな `length^l ~propの取得ではなく,その~prop~indexの集合についての内的~知識を利用するように,変更した。 ◎ Changed the algorithm for conversion from a platform object with indexed properties to a sequence type to use its internal knowledge of the set of property indexes rather than getting the "length" property, which may not even exist.
  • 32 ~bit型を選択する良い理由がない限り, `float^T より `double^T の利用が選好されることについての警告を追加した。 ◎ Added a warning to prefer the use of double to float, unless there are good reasons to choose the 32 bit type.
  • 演算~引数の既定~値に課される制約を、 “既定~値を持つ随意~引数の左側に位置するすべての随意~引数は既定~値を持たなければならない” に変更した(以前は、右側,とされていた)。 ◎ Changed the restriction on operation argument default values so that all optional arguments to the left of one with a default value must also have default values. (Previously, this was to the right.)