__plans__/beam-implementation.md

@@ -90,7 +90,7 @@ graph TD
   - Design storage layer (Mnesia/ETS)
 
 - **View System**
-  - Implement Lossy/Hyperview views
+  - Implement Lossy/Hyperviews
   - Create resolver framework
   - Add caching layer
 

__plans__/housekeeping.md

@@ -2,8 +2,8 @@
 
 - [x] Organize tests?
 - [x] More documentation in docs/
-- [x] Rename/consolidate, hyperview view() and compose() --> composeView()
-- [x] Rename Hyperview to HyperView
+- [x] Rename/consolidate, hyperview view() and compose() 
+- [x] Rename Lossless to HyperView
 - [x] Rename Lossy to View
 - [x] Consider whether we should use collapsed deltas
 - [ ] Improve ergonomics of declaring multiple entity properties in one delta

__tests__/integration/schema.test.ts

@@ -359,7 +359,7 @@ describe('Schema System', () => {
 
       debug(`Manually ingested invalid delta: ${JSON.stringify(invalidDelta)}`)
 
-      debug(`Hyperview view: ${JSON.stringify(node.hyperview.compose(), null, 2)}`)
+      debug(`Hyperview: ${JSON.stringify(node.hyperview.compose(), null, 2)}`)
 
       const validIds = collection.getValidEntities();
       expect(validIds).toContain('user1');

markdown/001-meeting.md

@@ -136,7 +136,7 @@ smalltalk type messaging structure on top of the database
 note dimensions of attack surface
 
 layers:
-primitives - what's a delta, schema, materialized view, view view
+primitives - what's a delta, schema, materialized view, view
 delta store - allows you to persiste deltas and query over the delta stream
 materialized view store - view snapshot(s)
 view bindings - e.g. graphql, define what a user looks like, that gets application bindings

markdown/004-library.md

@@ -34,7 +34,7 @@ Pre-built technologies? LevelDB
 Can use LevelDB to store deltas
 Structure can correspond to our desired ontology
 Layers for 
-- primitives - what's a delta, schema, materialized view, view view
+- primitives - what's a delta, schema, materialized view, view
 - delta store - allows you to persiste deltas and query over the delta stream
 - materialized view store - view snapshot(s)
 - view bindings - e.g. graphql, define what a user looks like, that gets application bindings

spec.md

@@ -13,6 +13,6 @@
 	* This could lead to circular references and arbitrarily deep nesting, which runs into the problem of "returning the entire graph". So our schema should specify, for instance, that the "friends" field apply the "Summary" schema to referenced users rather than the "User" schema, where the "Summary" schema simply resolves to username and photo.
 * A `hyperview` is a representation of an `object` that includes a full inventory of all of the deltas that compose that object. So for instance, a hyperview of the object representing the user "Alice" might include `alice.name`, which contains an array of all deltas with a pointer whose `target` is the ID of Alice and whose context is `name`. Such deltas would likely include a second pointer with the name `name` and the target a primitive string "Alice", for instance.
 	* A `hyperview` may also include nested delta/object layering. Consider `alice.friends`, which would include all deltas asserting friendship between Alice and some other person. Each such delta would reference a different friend object. In a hyperview, these references would be expanded to contain hyperviews of those friends. Schemas, as defined above, would be applied to constrain tree depth and avoid infinite regress.
-* A `view view` is a compression of a `hyperview` that removes delta information and flattens the structure into a standard domain object, typically in JSON. So instead of `alice.name` resolving to a list of deltas that assert the object's name it might simply resolve to `"alice"`.
+* A `view` is a compression of a `hyperview` that removes delta information and flattens the structure into a standard domain object, typically in JSON. So instead of `alice.name` resolving to a list of deltas that assert the object's name it might simply resolve to `"alice"`.
 	* Note that in a hyperview any property of an object necessarily resolves to a set of deltas, even if it's an empty set, because we cannot anticipate how many deltas exist that assert values on that context.
-* In collapsing a hyperview into a view view we may specify `resolution strategies` on each field of the schema. A resolution strategy takes as input the set of all deltas targeting that context and returns as output the value in the view view. So if we have 15 deltas asserting the value for an object's name, our resolution strategy may simply say "return the target of the `name` pointer associated with the most recent delta", or it may say "return an array of names". If the value is numeric it may say "take the max" or "take the min" or "take the average".
+* In collapsing a hyperview into a view we may specify `resolution strategies` on each field of the schema. A resolution strategy takes as input the set of all deltas targeting that context and returns as output the value in the view. So if we have 15 deltas asserting the value for an object's name, our resolution strategy may simply say "return the target of the `name` pointer associated with the most recent delta", or it may say "return an array of names". If the value is numeric it may say "take the max" or "take the min" or "take the average".

src/collections/collection-basic.ts

@@ -18,7 +18,7 @@ export class BasicCollection extends Collection<TimestampResolver> {
     id: string
   ) {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
 

src/collections/collection-relational.ts

@@ -17,7 +17,7 @@ export class RelationalCollection extends Collection<RelationalView> {
     id: string
   ): ResolvedViewOne | undefined {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
 

src/collections/collection-typed.ts

@@ -63,7 +63,7 @@ export class TypedCollectionImpl<T extends Record<string, unknown>>
 
   resolve(id: string): ResolvedViewOne | undefined {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
     return res[id];

src/views/view.ts

@@ -50,7 +50,7 @@ export abstract class Lossy<Accumulator, Result = Accumulator> {
 
     if (!hyperviewPartial) {
       // This should not happen; this should only be called after the hyperview has been updated
-      console.error(`Hyperview view for entity ${entityId} not found`);
+      console.error(`Hyperview for entity ${entityId} not found`);
       return;
     }
 

todo.md

@@ -186,7 +186,7 @@ This document tracks work needed to achieve full specification compliance, organ
 
 1. **Phase 1** ✅ - These are foundational requirements
 2. **Phase 2.1 (Negation)** ✅ - Core spec feature that affects all views
-3. **Phase 2.2 (Resolvers)** ✅ - Needed for proper view views
+3. **Phase 2.2 (Resolvers)** ✅ - Needed for proper views
 4. **Phase 2.3 (Nesting)** ✅ - Depends on schemas and queries
 5. **Phase 3 (Query)** ✅ - Unlocks powerful data access
 6. **Phase 4 (Relational)** - Builds on query system