May be rename COObjectGraphContext to COObjectGraph

[qmathe]

I initially pushed for COObjectGraphContext to be named as such. This creates a symetry with COEditingContext, since they both act as contexts that manage respectively fine-grained objects (aka inner objects) and coarse-grained objects (aka persistent roots).

However it's causing a lot of verbosity issues, especially in EtoileUI where every single initializer needs to be passed an object graph.

I also observed that renaming COObjectGraphContext to COObjectGraph would also increase the symetry with the low-level API that Core mirrors:

• low-level API: COSQLiteStore, COPersistentRootInfo, COBranchInfo, COItemGraph, COItem, CORevisionInfo
• high-level API: COEditingContext, COPersistentRoot, COBranch, COObjectGraphContext, COObject, CORevision

If we make this change, COItemGraph & COItem are nicely mirrored as COObjectGraph & COObject in the high-level API. So in the end, I'm in favor of this change ;-)

Following this line of reasoning, we might argue that COEditingContext could be better named COStoreSnapshot or something similar. Unless we find a better name, I'm much more reserved about this change, since COStoreSnapshot seems to describe a static data object, not something mutable, editable and which supports commits. Any suggestions?

COStoreSnapshot sounds more like the result of a commit or a slice of a store. In fact in Placeboard, I have a class COStoreSnapshot that represents a partial snapshot of the store state, basically a set of persistent root snapshots packaged together to be sent over a network connection.

imo we can stick to COEditingContext, it sounds clear enough.

[ericwa]

I support COObjectGraphContext -> COObjectGraph, feel free to do a find/replace.

Yeah, I think COStoreSnapshot gives the wrong impression for COEditingContext. Alternate names could be COPersistentRootManager or COStoreManager. Editing context is a decent name though.

[qmathe]

ok, I'll do this then.