> That, and that the existing builtins already impose those limitations -
and only class allows you to do those things, with them.
I’m surprised by that statement — it appeared to me that it currently
remains possible to create classes, including classes that extend
built-ins, with class syntax.
```
const test = value => {
if (typeof value !== 'string') throw new TypeError('nope');
return value;
};
function StringSet(init) {
if (new.target === undefined)
throw new TypeError('StringSet is not a constructor');
if (init !== undefined)
init = Array.from(init, test);
return Reflect.construct(Set, [ init ], new.target);
}
Reflect.defineProperty(StringSet.prototype, 'add', {
configurable: true,
value: Object.setPrototypeOf({
add(value) {
return super.add(test(value));
}
}, Set.prototype).add
});
Reflect.defineProperty(StringSet.prototype, Symbol.toStringTag, {
configurable: true,
value: 'StringSet'
});
Reflect.setPrototypeOf(StringSet, Set);
Reflect.setPrototypeOf(StringSet.prototype, Set.prototype);
new StringSet('abc');
```
Not that this is something one is apt to want to do normally, though it
being possible does remain useful sometimes for meta/compositiony stuff. It
cannot be achieved in an <= ES5 environment, but it seems all the
reflection tools needed are present in environments that actually have
class syntax — even, despite the awkwardness necessitated by HomeObject
stuff, what is needed to employ super in methods.
I’m curious if, aside from the possibility of implementation-specific
things like type error messages being different, there there is anything
about the above class which ends up observably different from the ES-side
from one created with class syntax instead?
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
