Should compositeKey be in a module

[bmeck]

It seems weird to have it hang off of all the existing globals.

[zloirock]

I don't think that it's time to use built-in modules. At this moment, too many questions about built-in modules and they will be resolved not soon. You will have many problems with polyfills. compositeKey looks like a simple and already finished conception. Symbol constructor looks like the best place for it because it returns a symbol and works like Symbol.for. Upd: I see that the proposal updated and now compositeKey returns an empty object, so the previous sentence not actual and in this case it should be Object constructor.

[bmeck]

@zloirock I'm not sure it should be on the Object constructor. It isn't something that you can mutate and doesn't have Object in the prototype. Why should it be on the constructor?

[zloirock]

@bmeck Object.create also can create objects without Object.prototype in prototype chain. Object.setPrototypeOf used for changing prototypes, etc. But they are on Object constructor. This method returns a frozen plain object without a prototype, this object haven't any exotic slots and Object#toString calling on it will return [object Object], so I don't see any other related places. I'm not a fan of returning an object from this method, symbols looks more interesting and logical for me, but it's not related this issue -)

[zloirock]

The main idea from my comment that built-in modules conception still not ready for usage, but this method can be specified and implemented soon.

[bmeck]

The main argument for having an object is to allow it to be used in WeakMaps which @wycats pointed out as an important use case for tying lifetimes together. If you want to discuss that, it can be done in a separate issue.

I'm not concerned with speed of landing things as much as moving things to the right location. I'm not convinced that placing this API on a global has any advantage except status quo, and it feels off to me.

[zloirock]

@bmeck I wanna implement it in core-js. So where should I place it now, without built-in modules, by your opinion?

[bmeck]

@zloirock at stage 1? IDK, API is still very unstable and the use case is still being looked into. You could make it a global for testing purposes, but I wouldn't ask people to ship this specific API anytime soon since it likely will have changes.

[zloirock]

@bmeck core-js includes proposals, for people who wanna play with experimental features. Early stage features implementation can help find possible problems. Breaking changes added only in major releases, so it's enougth stable.

[bmeck]

For now I'd lean on it just being a global function, feels better to me than putting on existing globals.

[bmeck]

After recent upheaval around naming of globally accessible identifiers (smoosh, globalThis, flat, ...) I'd still prefer it be on a builtin module. Still, i think this can be solved when going for stage 3 rather than immediately.

[ljharb]

Can https://github.com/bmeck/proposal-richer-keys/tree/master/compositeKey#where-will-it-live be updated to indicate both possibilities? It’s not clear to me that builtin modules will ever be able to advance, and I’d prefer not to see this proposal blocked on them.

[bmeck]

@ljharb given my preference for a module, I won't be updating it at this time.

[ljharb]

I don’t see how this can possibly qualify for stage 2 if it depends on a stage 1 proposal.

[bmeck]

@ljharb I consider an initial spec text to be doable without directly defining the location. Similar to how global does not revert stages when finding the proper location it should live on.

[ljharb]

The final location can change, but it typically changes from something that exists, to a different thing. I consider “a builtin module or not” as a question that needs, at the least, an explanation for the case of either answer, prior to stage 2.

[bmeck]

@ljharb

I'd note that if TC39 allows host based specifier for builtin modules, similar injection would be required for them.

The final location can change, but it typically changes from something that exists, to a different thing. I consider “a builtin modules not” as a question that needs, at the least, an explanation for the case of either answer, prior to stage 2.

I take it that an explanation of why would be sufficient then, even if a location is not determined?

[ljharb]

What i mean is, I’d expect to see a concrete location, for the imo likely event that builtin modules never advance.

[bmeck]

@ljharb I do not wish to propose what I see as a less than optimal location. Therefore, any location would be concrete on a builtin module currently. I will not be proposing a global location currently since as stated the intent is to propose this on a builtin module. If a concrete location is on a builtin module record the specifier on how to reach that module does not seem to be required to test the module itself.

[ljharb]

It’s not clear that we will ever be able to omit creating new globals, even with builtin modules, nor is it clear builtin modules are even viable. If a proposal lacks a concrete non-module location, then i don’t think it can advance to stage 2, since we shouldn’t be committing to putting a feature in the language if its foundation lacks the same commitment.

[bmeck]

@ljharb I agree that globals will grow over time. My discomfort with globals still stands and I do not find putting a location I find as sub-optimal and uncomfortable as something I would seek to move forward with. I remain of the mind that location is not a foundational part of this API when compared to other proposals that change location during stages later than 2. As such, it is not a useful conversation to try and force a decision at this stage. In particular, it is even less useful to force a location that will be sought to change if possible.

[bmeck]

this issue is a holdover from when this proposal had more features, the more minimal collection normalization proposal doesn't have this. closing.