Why this over the previous keyBy idea?

[Jamesernator]

So this proposal currently tries to replace both the compositeKey proposal and records/tuples by introducing composite objects to fufill both purposes.

However as from the other issues this has a number of problems:

• keys can't be interned (and therefore === equal) without making some objects unusuable in weakmaps
• keys can't hide private information so it's hard to avoid leaking private details if used in a shared set/map
• keys have to be composites and so can't allow existing classes to opt-in to re-keying (no current issue, but [[Prototype]] issues are related)

These problems weren't suffered by the previous keyBy proposal, and it's not clear to me how this proposal solves the problems of either records/tuples or key-ing better than that proposal.

For one in that proposal we could easily opt-in existing objects to the re-keying protocol:

class Point {
    readonly x: number;
    readonly y: number;

    // ...constructor

    [Symbol.reKey](): CompositeKey {
        return new CompositeKey(this.x, this.y);
    }
}

const s = Set.keyed();

s.add(new Point(3,4));
s.has(new Point(3,4)); // true

The proposal also had a pretty good path for record/tuples, just builtin objects with reKey in their prototype:

const r1 = #{ x: 10, y: 20 };
const r2 = #{ x: 10, y: 20 };

CompositeKey.equal(r1[Symbol.reKey](), r2[Symbol.reKey]());
// This could plausibly even be a dedicated function, which is essentially just
// equivalent to the above
Composite.equal(r1, r2);

Further if we were to use symbols as suggested we could even use === for composite key equality:

r1[Symbol.reKey]() === r2[Symbol.reKey](); // true

[acutmore]

I was also exploring that space in https://github.com/acutmore/proposal-keyby

This introduces a new 'kind' of map. Developers use Object.create as a map, also new Map and now also have Map.keyed() to chose from. I'd like to look for a solution where developers can 'just' use new Map(). Especially now we have Set methods, we have to think about what it means to do regularSet.union(keyedSet) vs keyedSet.union(regularSet).

What should the Symbol.reKey protocol return? If it returns objects that are === equal then that means either all composite keys must contain an object (memory leak risk) or some objects can't be used in a WeakMap.

Symbol.reKey means that data has to be converted into something else each time a lookup is performed. The idea with composites is that they can be the data. This avoids the need to add caching boilerplate (if we had decorators that would reduce some boilerplate).

Similarly, the downside to private keys is that data has to be converted into a new value to check its equality, instead of using the data directly. Even with private keys it's possible to expose the data via brute force. That said I would like to explore privacy with composites, though I think that the majority of uses cases do not need that level of privacy. The common use cases are 'public structs'.

The proposal also had a pretty good path for record/tuples,

This also works with the current design. #7. #{ x: 1, y: 4 } can produce a composite.

[Jamesernator]

I was also exploring that space in https://github.com/acutmore/proposal-keyby

Yes this is the proposal/idea I was refering to.

This introduces a new 'kind' of map. Developers use Object.create as a map, also new Map and now also have Map.keyed() to chose from.

I don't know that it's really a new "kind" of map so much as just a configuration option for existing maps/sets (in a similar vein, "resizable" array buffers are still just ArrayBuffer even though they have different behaviour).

(And yes people use Object.create as maps too, but usually that is for compatbility with things like JSON (which Map doesn't resolve) or simply because of historical inertia).

I'd like to look for a solution where developers can 'just' use new Map().

I highly doubt I am the only one heavily wanting both weak-composites and integration with existing classes, neither of which will just work with new {Weak}Map() regardless. Refactorings will be necessary for a lot of things to really use composites, however at least reKey allows existing objects to easily opt-in to the behaviour.

we have to think about what it means to do regularSet.union(keyedSet) vs keyedSet.union(regularSet)

This is as far I can see really the only disadvantage of the previous idea that isn't easily resolved, but at the same time I question why people would ever want to take the difference of sets with different key-ing strategies. It feels like largely an anti-pattern to ever do this that I feel it wouldn't matter what is done here.

(Also sets already have to deal with this as .union and friends already can take arbitrary set-likes e.g. new Set([1,2,3,4]).intersection({ size: 5, has(x) { return x % 2 === 0 }, *keys() { yield* [0,2,4,8,10] } }) already works today).

What should the Symbol.reKey protocol return?

It could return anything, but more important is what compositeKey returns. I feel the answer here is just to go with symbol as suggested.

This allows us to have registered symbols (i.e. not allowed in weakmaps) with compositeKey(1,2) but weak (i.e. non-registered) symbols for those that have a weak member (e.g. compositeKey({},3,4)).

Symbol.reKey means that data has to be converted into something else each time a lookup is performed. The idea with composites is that they can be the data. This avoids the need to add caching boilerplate (if we had decorators that would reduce some boilerplate).

This proposal doesn't avoid the problem. For non-composite objects in the current proposal we would need to something like this anyway:

class Point {
    // ...

    toKey() {
        return Composite({ x: this.x, y: this.y });
    }
}

const s = new Set();
s.add(new Point(3,4).toKey());
s.has(new Point(3,4).toKey()); // true

For records/tuples/composites, it would up to implementations whether the symbol returned from reKey is cached or not, there's no way this caching is observable anyway as composites contain all parts of the key so can necessarily revive the key anytime.

Similarly, the downside to private keys is that data has to be converted into a new value to check its equality, instead of using the data directly.

Even in your previous idea you already suggested the decorator:

class SomeClass {
    @CompositeKey.field
    #field = Math.floor(Math.random() * 5);

    [Symbol.reKey]() {
        return CompositeKey.for(this);
    }
}

if we go further and even have implementations generate the reKey method themselves with a class decorator:

// Generates SomeClass.prototype[Symbol.reKey] and whatever hidden data the engine
// needs/wants for effective comparison when adding to sets
@CompositeKey.class
class SomeClass {
    @CompositeKey.field
    #field = Math.floor(Math.random() * 5);
}

// Optional: Equivalent to calling reKey on it's arguments, but engines could skip this step if reKey
// has optimization information (e.g. when decorators are used, or for records/tuples)
compositeKey.equal(new SomeClass(), new SomeClass());

then implementations could freely choose between interning and using the data fields directly when comparing such objects (or adding them to sets, or other such things).

Or even more simply, maybe only records/tuples defined with syntax have this optimized behaviour and reKey simply performs worse for class-based objects (which it will do so with the current proposal if we have to generate Composite({ ... }) from those objects anyway).

[acutmore]

For non-composite objects in the current proposal we would need to something like this anyway:

One idea is that some data can be composites itself. Maybe something like this would be allowed (if Composite was a constructor, #11 ):

class Position extends Composite {
    constructor(x, y) {
        super({ x, y });
    }

    add({ x, y }) {
        return new Position(this.x + x, this.y + y);
    }

    get length() {
        return Math.sqrt(this.x * this.x + this.y * this.y);
    } 
}

Or maybe better syntax along the lines of tc39/proposal-structs#62

This all said, I think the primary question we need to answer first is #15. Almost all of the other design questions hinge on that question, as most of my original thinking for this proposal was made with the assumption that interning was off the table.

[Maxdamantus]

One idea is that some data can be composites itself. Maybe something like this would be allowed (if Composite was a constructor, #11 ):

class Position extends Composite {
    constructor(x, y) {
        super({ x, y });
    }

    add({ x, y }) {
        return new Position(this.x + x, this.y + y);
    }

    get length() {
        return Math.sqrt(this.x * this.x + this.y * this.y);
    } 
}

FYI, even if Composite isn't a constructor, something like this should work out-of-the-box, just as long as custom prototypes are supported (#4, #5):

class Position {
    constructor(x, y) {
        return Composite({ x, y }, Position.prototype);
    }

    add({ x, y }) {
        return new Position(this.x + x, this.y + y);
    }

    get length() {
        return Math.sqrt(this.x * this.x + this.y * this.y);
    } 
}

imo it might be nice to have special class support in the future, particularly if private fields are desired (they won't work using the above pattern where the constructor returns). But the fact that the above code should just work without any further spec changes might be a motivating reason to allow custom prototypes in the initial release.