Feeback - Syntax and Behaviors

[Karric]

Naming
Not every programming term is clear, but Composites to me is not clear on implied behavior. Based on the functionality described so far, I'd recommend any of the following names:

if class
	from language:
		par (latin for equal, equal-sized, well-matched)
		collage
		semblance
		congruent
		congruous
		consonant

	from academia (LLM assisted; I verified meaning):
		Isomorph
		Bijective
		Invariant
		Allotrope
		Anagram
		Affine

if method:
	Object.imitable()
	Object.isomorphic()
	Object.congruous()

Class vs Method
Considering this proposal is largely about modifying current behavior (equality algorithm) on a per-object basis, there's small precedence with Object.freeze and Function.bind who also change default behaviors. I would argue this is a flag/slot on the object to be utilized by others and should be set via method, as described in this post. This allows a developer to leverage the current equality early on and then at some point downstream decide to change equality behavior. This is not anti-foresight, it's just giving developers choice.

myArr.composite();
myObj.composite();
// Object.freeze cannot be undone, but perhaps myObj.composite could be, via passing a boolean.

Composite Properties Enumerable
The language for this section (here) is unclear, whose keys are enumerable? The Composite's internal value obj/arr? If it's Composite itself, then that clashes with the transparent operation style from the rest of the proposal, since being able to do key in/of obj is very common.

Obscured typeof / constructor / instanceOf
I've written recursive algorithms where I must figure out what the turn value's 'type' is as the next action depends on that. I absolutely do not want to have to add isComp = Composite.isComposite( turnValue );. For cases like serialization it may be moot, as I would care about the contents, but for cloning or interrogation it would be preferred to have constructor or instanceOf expose the correct type. BigInt and Async Function got their own despite being 'variants' of existing types. This is already wonky in JS, but I would try to gravitate towards consistency instead of inconsistency.

Proxy
Proxy has some design choices that may be relevant:

• Extraction - I did not see any explicit language in the proposal where like Proxy, one cannot extract the original object from the wrapper by design. If that's desired maybe mention it.
• Set/get traps - I'm a big fan of set/get traps, they are highly useful and I wish I didn't have to use a Proxy to have them. That said, you did not explain why "A proxy with a composite as its target is not considered a composite" here. If composite is highly transparent with minimal behavior change, then the interaction with Proxy should not be different from non-composites.

Final Notes
Considering this proposal is largely a commentary on the equality algorithm, I feel like it might make more sense to directly attack the problem; rather than a new implicit equality, propose a new explicit equality. Perhaps equality itself deserves a global entity with methods.

[acutmore]

there's small precedence with Object.freeze and Function.bind who also change default behaviors.

A goal of the proposal is that equality is consistent. Modifying the equality of an existing object would break that goal, for example:

const a = {};
const b = {};
const s = new Set([a, b]);
s.size; // 2

Object.congruous(a);
Object.congruous(b);

a and b are now equal. If s.size is still 2 that is inconsistent. If s.size has become 1 then we've been able to change the set indirectly which would add complexity to implement, makes these collections harder to reason about, and creates a subtle communication channel.

[Karric]

const a = {};
const b = {};
const s = new Set([a, b]);
s.size; // 2

Object.congruous(a);
Object.congruous(b);

a and b are now equal. If s.size is still 2 that is inconsistent. If s.size has become 1 then we've been able to change the set indirectly which would add complexity to implement, makes these collections harder to reason about, and creates a subtle communication channel.

That side-effect could be desirable, but yes its very problematic and I doubt it would be acceptable from a language perspective. In which case, Object.congruous(a) would have to be non-retroactive -- s would not change (still a strong reference to a/b), but if you made a new set s2 with a/b after becoming congruous, that set would be size=1. So this congruous flag is only checked on ingestion. Toggling congruous would have its uses, and I'd prefer toggling the state of one variable over having a congruous copy floating around.

Considering this proposal is largely a commentary on the equality algorithm, I feel like it might make more sense to directly attack the problem; rather than a new implicit equality, propose a new explicit equality. Perhaps equality itself deserves a global entity with methods.

I'm still not terribly sold on the solution being (yet another) special kind of collection. I worry it'll cause defensive coding where it is used instead of Map/Set 'just in case', and the mental tax of having to remember 'this variable is effectively this type but also composite therefore...`. There may be some annoyance that you have to use a Composite just to gain the congruous method. If that congruous algorithm does not need historical/privileged information to work, then it might as well be on-demand and offered more generally.

To be perfectly honest, something like Equality.congruous(a,b) / Set.hasCongruous(a) / Map.hasCongruous(a) => <boolean> is far more attractive to me, as it would be much easier to ensure isolation, only requires a new equality algorithm, more clearly mutation/side-effect free, is on-demand, avoids ramifications with the rest of the language, and Equality could be a new general-use API that can be extended to address inconveniences like Object.hasOwn/Map.has/Set.has/Array.includes => Equality.has(setOrArrOrMapOrObj, key);

I happen to be in the middle of creating a DataStructure class at work; you provide it a template (all data types supported) and can ask for a new instance of that template with the option to merge data into the new instance at that time. This involves walking and comparing 2 data structures recursively to ensure the 'shape' is the same (deep clone). This borrows from a JSON 'calculator' I made prior, where you can add/subtract JSON blobs from each other (ie, merge, diff, etc), with various heuristics. It's straightforward until you hit list-like collections; then you have to contend with "does the size/order of the list matter"?

---

Addendum
My comments above about an alternative API; I don't mean to sound dismissive of the proposal thus far, or to push a rewrite, I do feel its already useful, I'm just exploring the other implementation angles (methods on existing types, global operations-oriented entity).

[jason-ford-x]

@acutmore I've been a bit inspired and fleshed out the Equality API I alluded to above. I do believe it satisfies your objectives while providing lots of other value for the language. Would you prefer I share that as a separate (competing) proposal or directly to you?

https://github.com/jason-ford-x/proposal-equality