Module object_array 

Functions

accessor_only_keys

accessor(getter/setter) 専用プロパティのうち props に無いキーだけを返す （props 側に同名の通常プロパティがあればそちらを優先し二重にしない）。

array_ctor 🔒

array_from 🔒

array_from_async 🔒

Array.fromAsync(iterableOrLike, mapFn?, thisArg?)（ES2024/2025 相当）。 本来は非同期イテレータプロトコル（Symbol.asyncIterator）にも対応するが、この処理系には まだ for-await-of / 非同期イテレータが無いため、同期イテラブル（配列・Set・Map・ generator・文字列・array-like）を対象に、各要素が Promise ならその場で await する 簡略実装。戻り値は仕様どおり Promise でラップする。

array_index_key 🔒

文字列キーが仕様上の「配列インデックス」（"0"〜"4294967294"、先頭ゼロ無し） かどうかを判定し、そうならその数値を返す（ECMA-262 CanonicalNumericIndexString/ IsArrayIndex 相当の簡略判定）。

array_is_array 🔒

Array.isArray(v)。仕様上は Proxy を透過して target を見る必要がある （以前は Proxy でラップした配列が false 判定になっていた）。 Array.isArray(v)。TypedArray も内部表現は ObjKind::Array を流用するため、 _ta_kind タグの有無を見ずに判定すると Array.isArray(new Int8Array(...)) が 仕様に反して true になるバグだった（TypedArray は Array exotic object では ないため、仕様上ここは常に false になるべき）。

boolean_ctor 🔒

is_internal_host 🔒

ObjKind::Host は DOM プロキシ(style/classList/dataset/storage/document)や make_iterator() の内部状態(_items/_pos)を .props に格納する「内部実装専用」の 種別で、仕様上は列挙可能な own プロパティを持たない（実データは別経路にある）。 Object.keys/values/entries/assign/JSON.stringify がこれを素通りして .props を直接列挙すると、make_iterator() 導入で新たに _items/_pos という 内部実装詳細が Object.keys(arr.values()) 等から見えてしまうバグがあった。

is_symbol_like_key 🔒

この処理系には実の Symbol 型が無く、Symbol.iterator 等の well-known symbol は "Symbol(Symbol.iterator)" という見た目のリテラル文字列で代用されている （obj[Symbol.iterator] = fn は内部的に obj.props["Symbol(Symbol.iterator)"] = fn という通常の文字列キー代入に化ける）。仕様上 Symbol キーは Object.keys/values/ entries/for...in/JSON.stringify/スプレッド構文等のあらゆる「文字列キー列挙」から 除外されるべきだが、これらの区別が無かったため、class Range { [Symbol.iterator](){} } のようなカスタムイテラブルの Symbol.iterator メソッド自体が列挙結果に漏れて見える バグだった（Object.assign/Reflect.ownKeys は仕様上 Symbol キーも対象のため 意図的にこのフィルタを適用しない）。

number_ctor 🔒

object_assign 🔒

object_ctor 🔒

object_entries 🔒

object_keys 🔒

object_values 🔒

own_enumerable_entries 🔒

Object.assign の1ソース分の「自身の列挙可能プロパティ」を集める。 以前は s.borrow().props を直接見るだけだったため、(1) Proxy（自身は props を 持たず target 側にある）と (2) 配列（要素は props ではなく ObjKind::Array 側にある） の2種類のソースからは何もコピーされないバグだった。

spec_key_order 🔒

ECMA-262 OrdinaryOwnPropertyKeysが要求する2段階の列挙順序へ並べ替える: (1) 配列インデックス風のキーを数値昇順で先頭に、(2) 残りのキーは元の順序 （propsがIndexMapのため既に挿入順）のまま後ろに続ける。Object.keys/ .values/.entriesが丸ごと文字列の辞書式順序（旧BTreeMap由来）だった バグの残り半分（数値キー優先順序）を解消する。2026-07-18 発見・実装。

string_ctor 🔒

unwrap_proxy_target 🔒

Object.keys/values/entries は Proxy を素通ししてしまうと（Proxy 自身は props/ObjKind::Array を持たないため）常に空になるバグだった。ownKeys/ getOwnPropertyDescriptor トラップの呼び出しまでは行わない簡略実装だが、実用上多い 「target にフォワードするだけの Proxy」のケースはこれで正しく動くようになる。