Composite(…) vs. new Composite(…)

[js-choi]

Why not new Composite(…)? The current proposal uses Composite(…). Do we want a class or not a class?

@eemeli first raised this at plenary, and I was wondering about this too.

[jakearchibald]

The returned object isn't an instance of Composite. Although this is possible with constructors in JS, it's a weird pattern.

[eemeli]

While the current value returned by Composite() is not an instance thereof, my question in committee was essentially, "why isn't it?" I don't have very strong feelings on this one way or another, but if it ought not be a class, I would prefer to hear a clearer story about the reasons for that

[ljharb]

Because then it'd have a mutable object as its [[Prototype]], and unchecked property access on it wouldn't be safe?

[hax]

I also think there’s a bit of contradiction in the fact that, on one hand, it’s not a class, yet on the other hand, it requires isComposite—which feels weird (any precedent?). If we argue that it behaves more like a proxy, then proxies, in contrast, must be created using new Proxy.

[ljharb]

It doesn't have to be a class to have internal slots. You can't new Symbol() but it has internal slots, and it's not even an object.

[jakearchibald]

#5 discusses the pros/cons of prototypes carrying over to the composites.

Cross-realm equality is the most important imo.

[mhofman]

on the other hand, it requires isComposite—which feels weird (any precedent?)

• Array.isArray ? The prototype is independent from the indexed access behavior.
• Error.isError? That tells you an object is an error as denoted by its internal slot, and which technically doesn't require to derive from Error.prototype.

isComposite tells you it has special equality semantics, not what its prototype chain is.

If we argue that it behaves more like a proxy, then proxies, in contrast, must be created using new Proxy.

Except for Proxy.revocable. Anyway I'd argue today that Proxy shouldn't have been a constructor.

[hax]

@mhofman
Array and Error can be new. Proxy.revocable is a static factory. So I mean, it seems there is no precedents that the constructor call would create an object instance (not primitive values) but can't new.

[jakearchibald]

it seems there is no precedents that the constructor call would create an object instance (not primitive values) but can't new.

There's also no precedents that a new Foo returns something that isn't an instanceof Foo. Yes it's possible, but I don't think any built-in constructor does this.

Just throwing an idea out there in case it unblocks anything:

Creating a composite:

const compositeObj1 = Object.composite({ foo: 'bar' });
const compositeObj2 = Object.composite({ foo: 'bar' });

Comparing a composite:

const result = Object.is(compositeObj1, compositeObj2); // true

If adding behaviour to Object.is is undesirable, or inheriting its behaviour is undesirable, we could add Object.isEqual or whatever.

[acutmore]

I strongly think Object.is needs to remain as the "SameValue" check.

The lack of new in the current proposal originates from my initial new take on Records and Tuples where Composite({}) would return something with a different prototype to Composite([]). With the conversation in #2 and #4 I am less sure that it makes sense for Composite([]) to be the trigger to get a different prototype.

We could switch to new Composite({}), but the core questions I think we need to first answer are:

• Are Composites interned? (Should composites be eagerly interned (=== equal) #15)
  • If they are then new makes less sense to pursue
• Custom prototypes (Should there be a way to choose the [[Prototype]]? #4)
  • If they are constructors then that likely means that we would allow class Position extends Composite {}, i.e. Reflect.construct(Composite, [{}], { prototype: { method } })

Instead of going too deep on what precedent there is for new vs a factory function. The proposal has only just got Stage 1 so the API may easily end up looking new different, e.g maybe it's Object.composite as @jakearchibald suggested, or Composite.from(val), or many other names+shapes variations.