ajvincent / composite-collection Goto Github PK

This will be required for #7.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields#browser_compatibility

Also an optional "The configuration for this file is at ..."

Template strings are an easier way to go, if messier.

... which is a hairy problem in and of itself.

sverweij/dependency-cruiser#336 is the closest I could find to what I need, more complex than eslint but not designed for unit tests.

Example: KeyHasher must store non-primitive keys weakly. Truly verifying that would require analysis of an abstract syntax tree (AST), trying to trace an entry point (an argument in one function) to points that assign or store a value. I could see that requiring a few things, of which I only know I need the first three:

• An Acorn-generated AST.
• Maybe a tree-walking tool to invoke traps for certain AST node types.
• An entry tuple to pass in and start the analysis, looking for any assignment or storage which returned false for a rejected state (meaning a strong reference).
• A composite set for assignment and storage nodes, with test functions returning true ("accept"), false ("reject") or undefined (for "unknown, dig deeper").
• A composite set of tree nodes representing arguments and return / throw values from one function to another.
• A "non-deterministic finite automation" (also known as a state machine) combining the previous two sets and a starting point.
  • Because of the changing nature of this and/or stack traces, the automaton might need to become a "push-down automaton", which is just lovely for the added complexity.

Crafting this would be ugly, but the composite collections I'm building could make it easier, ironically enough.

Honestly, the complexity of this type of analysis could result in a complementary project, where each one uses the other as a development dependency...

Otherwise, it leaks memory for holding a bunch of WeakSets or WeakMaps.

I created the eslint branch, but this requires eslint to support private class fields - which it won't until after ECMAScript 2022 goes official in June 2022. I could make it work by using @babel/eslint-parser, but I think that locks me in with much pain trying to convert from one engine to another for future work.

• Users may prefer a non-default export.
• In the "key groups" case (#4), there will likely be intermediate container classes which the code generation shouldn't export.

https://jakejs.com/docs-page.html#section-overview

Why should people have interest in this project?

if (!this.has(args))
  this.set(args, defaultValue);
return this.get(args)

With the number of arguments and work we have to do, providing a built-in method for this is probably a good idea.

spec/integration/combinations.mjs should:

1. Create configurations out of combinations
2. Write generated code for each configuration to a temporary file
3. Load the file as a module and confirm the module exports a syntactically valid class
4. Delete the temporary file

This should produce 16 unique classes.

For good measure, I can also include combinations classes for 3 levels of map keys (8) and 3 levels of set keys (8).

In particular, we can't let an argument validator lambda function explicitly throw.

This will make one-to-one hashtables possible.

• groupName will provide a subclass for keys
• typeCallback will hook into the addMapKey() method and its friends TBD
• equalityCallback will allow the generated code to substitute one composite key for another.

In particular, if an add or set operation fails, throw an exception. This makes it clear something went wrong.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry

Waiting on Safari.

Bootstrapping! https://en.wikipedia.org/wiki/Bootstrapping_(compilers)