Removes some unnecessary Gallicisms, changes anonymous class name.

README.md

@@ -348,7 +348,7 @@ Steps are executed sequentially. The result of a query is the intersection of ea
 
 ```typescript
 ctx.query
-  .some.components(A, B) // (A | B)
+  .any.components(A, B)    // (A | B)
   .all.tags('one', 'two'); //  & ('one' & 'two')
 ```
 
@@ -402,7 +402,7 @@ This means that overhead associated with creating a new query each `tick()` is _
 
 ## Saving & Loading
 
-Being able to export the game state to a serializable format and reloading it later is important. And since that is the case, it's also intended to be pretty straightforward. The output is a bulky POJO—in a purely naïve dump, ~2000 entities runs me about 650 KB. There are a number of strategies you can use to reduce the size of this output: entity filtering, custom component serialization and output compression.
+Being able to export the game state to a serializable format and reloading it later is important. And since that is the case, it's also intended to be pretty straightforward. The output is a bulky POJO — ~2000 entities runs me about 650 KB. There are a number of strategies you can use to reduce the size of this output: entity filtering, custom component serialization and output compression.
 
 ### Entity filtering
 
@@ -467,10 +467,10 @@ First, with a fresh install and having already run `build`, run <kbd>npm run ben
 **A/R**: Fine? It's... complicated.
 
 **Q/S**: ???  
-**A/R**: I would say it's comparable to other "rich" ECS implementations (e.g., Ecsy) and poor relative to some other lower-level ECS libraries (bitecs, wolfecs). It's not a performance-oriented implementation, but it's also not a naïve one. Particularly awesome performance has never been a primary design goal (so long as it remains capable of 60 FPS+, features are (currently) a higher priority than performance improvements) and I'm sure there's plenty of low-hanging fruit remaining for performance gains.
+**A/R**: I would say it's comparable to other "rich" ECS implementations (e.g., Ecsy) and poor relative to some other lower-level ECS libraries (bitecs, wolfecs). It's not a performance-oriented implementation, but it's also not a totally naive one. Particularly awesome performance has never been a primary design goal. So long as it remains capable of 60 FPS+, ergonomics are a higher priority than performance. And I'm sure there's plenty of low-hanging fruit remaining for performance gains.
 
 **Q/S**: Real-world example?  
-**A/R**: Using a naïve culling implementation and PIXI for rendering, a 256×256 map from [FLARE](https://github.com/flareteam/flare-game) runs at 5ms/frame with ~40MB memory usage.
+**A/R**: Using a crude culling implementation and PIXI for rendering, a 256×256 map from [FLARE](https://github.com/flareteam/flare-game) runs at 5ms/frame with ~40MB memory usage.
 
 **Q/S**: After reading the code, I am shocked, _shocked_ to find that this is less type-safe than I would have ever thought possible.  
 **A/R**: This is correct. Unfortunately, this library and its design are more about ergonomics and ✨ my feelings ✨ than bulletproof type-safety.

src/types.ts

@@ -14,8 +14,8 @@ export type UnionToIntersection<Union> = (Union extends unknown ? (distributedUn
   : never;
 
 // There's certainly a better way to handle this, but it appears to behave consistently enough—at least in Chrome...?
-export const anonymous = '__anon';
-export const eid = '$id$';
+export const anonymous = '__entity';
+export const eid = '__id';
 
 export const Components = 'Components';
 export const ToDestroy = 'ToDestroy';

src/utils/useWith.ts

@@ -21,30 +21,30 @@ export function useWithComponent<T extends BaseType, A extends ComponentClass[]
   // we're tracking entity class => component classes, allowing us to extend existing component sets.
   const curr = ctors.get(Constructor) ?? [];
   // we need to give each entity its own constructor
-  const __anon = class extends Constructor {};
+  const __entity = class extends Constructor {};
 
   // and we need to define this here because no other configuration permits
   // `items` to be accessible on the prototype while being not being subject to
   // changes in other items of the same type (via `.slice()` in the entity constructor)
   const value = [...curr, ...items];
-  ctors.set(__anon, value);
+  ctors.set(__entity, value);
 
-  Object.defineProperty(__anon.prototype, Components, {
+  Object.defineProperty(__entity.prototype, Components, {
     value: value.slice(),
     writable: true
   });
 
   // type system abuse
-  return __anon as unknown as EntityClass<T & KeyedByType<A>>;
+  return __entity as unknown as EntityClass<T & KeyedByType<A>>;
 }
 
 export function useWithPlugins<P extends PluginClass<R>[], R extends KeyedByType<P>>(
   ...items: P
 ): ContextClass<Merge<R>> {
-  const __anon = class extends Context<Merge<R>> {};
-  Object.defineProperty(__anon.prototype, 'items', {
+  const __ctx = class extends Context<Merge<R>> {};
+  Object.defineProperty(__ctx.prototype, 'items', {
     value: items.slice(),
     writable: true
   });
-  return __anon as unknown as ContextClass<Merge<R>>;
+  return __ctx as unknown as ContextClass<Merge<R>>;
 }