Subclassable built-ins tests (was: Add more tests from @awbjs) about compat-table HOT 14 CLOSED

I think @allenwb meant the RegExp u flag. AFAIK there is no such thing as the h flag.

from compat-table.

right "u". Full Unicode RegExp matching semantics.

Keyboard proximity error...

from compat-table.

A recent commit by me (that has already been merged) has implemented the @@hasInstance and @@toPrimitive tests.

from compat-table.

@webbedspace thanks, checked

from compat-table.

@@create has already been removed now as per recent spec updates.

from compat-table.

@webbedspace , but [[CreateAction]] was added instead

from compat-table.

it is a little hard to understand from the spec, how subclassing should work, but seems, subclassing will work only for class AbortablePromise extends Promise, not for inheritance we can use in ES5...

from compat-table.

[[CreateAction]] is not directly observable to userland code (unlike @@create), so adding a test for it seems both improper and difficult. The subclassing checks should instead suffice.

from compat-table.

Yes, [[CreateAction]] is only "inherited" via class definitions. But subclassability of all built-ins that have [[CreateAction]]'s should be tested. For example,
class MyArray extends Array {};
class MyDate extends Date {};
etc.

In each case, the special instance behaviors provided by the super class' [[CreateAction]] should be observably present on instances of the subclass. EG,

   let ma = new MyArray;
   ma[3]='three';
   assert(ma.length === 4);

from compat-table.

So, testing subclassability will mean applying the following checks to instances of the subclasses:

• Array: Dynamic .length behaviour
• RegExp: Can be used in String#match, I guess.
• Function: Can be successfully called and newed.
• Date: ???
• String: instance == a primitive with the same value.
• Number: instance == a primitive with the same value.
• Boolean: instance == a primitive with the same value.
• Promise: instance's resolving function is called when resolved.
• Proxy (i.e. the Proxy constructor): ??? (is this possible?)
• Error: ???
• Map: .set() works
• Set: .add() works
• WeakMap, WeakSet: ??? (Since WeakMap's GC behaviour is not observable, it's questionable whether this can be distinguished from Map and Set's tests.)

Additionally, the constructors need these tests:

• Array: .of() and .from() return instances of the subclass (already included in compat table) as well as .slice()
• Function: ???
• Promise: .resolve() and .reject() return instances of the subclass

(I'll need some more research to complete this list.)

from compat-table.

I was just about to add .length behavior, since our current test "extends (built-in constructors)" is a bit misleading in regards to at least IETP (which doesn't update length) as I noticed couple days ago.

from compat-table.

The main reason I split the extends test is because TypeScript and Closure have specific demands about what can be in the extends clause. The point of that test isn't to check that the instance has correct behaviour, but that the extends clause is accepted at all. So, I guess something like String should be put there instead of Array.

from compat-table.

I figured. We can maybe just leave that one as is (it'll be — "extends built-in constructors, basic") and add behavioral ones on top. Or add all of the above tests under that one? Would that be too much? Do we need a separate test, not just sub-test for it?

from compat-table.

Implemented by @webbedspace recently so closing

from compat-table.