Summary
#[boa(class)] currently supports string-named methods/properties but does not provide a direct way to expose symbol-named methods (for example Headers.prototype[Symbol.iterator]).
Motivation
In PR #4638 we had to manually register [Symbol.iterator] in core/runtime/src/fetch/mod.rs by constructing a function object and defining the symbol property on the prototype after js_module::boa_register.
This works, but it is verbose and duplicates boilerplate that should ideally live in the class macro path.
Requested enhancement
Add support in #[boa(class)] (and related derives/attributes) for symbol-keyed methods so builtins can declare these declaratively, similar to other method definitions.
Current workaround
Manual prototype patching is used in PR #4638 with a TODO to migrate once macro support exists.
References
Summary
#[boa(class)]currently supports string-named methods/properties but does not provide a direct way to expose symbol-named methods (for exampleHeaders.prototype[Symbol.iterator]).Motivation
In PR #4638 we had to manually register
[Symbol.iterator]incore/runtime/src/fetch/mod.rsby constructing a function object and defining the symbol property on the prototype afterjs_module::boa_register.This works, but it is verbose and duplicates boilerplate that should ideally live in the class macro path.
Requested enhancement
Add support in
#[boa(class)](and related derives/attributes) for symbol-keyed methods so builtins can declare these declaratively, similar to other method definitions.Current workaround
Manual prototype patching is used in PR #4638 with a TODO to migrate once macro support exists.
References
core/runtime/src/fetch/mod.rsmanual symbol wiring block