I might rearrange these as follows (🔮 indicates classes that aren't created yet):

• MediaWiki\Storage
  • ---- blob access
  • BlobAccessException
  • BlobStoreFactory
  • BlobStore
  • SqlBlobStore
  • ---- name table access
  • NameTableAccessException
  • NameTableStoreFactory
  • NameTableStore
• MediaWiki\Revision
  • ---- revision storage (on the border between MediaWiki\Storage and MediaWiki\Revision)
  • RevisionFactory
  • RevisionLookup
  • RevisionStoreFactory
  • RevisionStore
  • ---- revision records
  • RevisionRecord
  • MutableRevisionRecord
  • RevisionArchiveRecord
  • RevisionStoreRecord
  • RevisionSlots (or maybe in MediaWiki\Revision\Slots)
  • MutableRevisionSlots (same)
  • ---- revision exceptions
  • IncompleteRevisionException
  • RevisionAccessException
  • SuppressedDataException
  • ---- revision rendering
  • RevisionRenderer
  • RenderedRevision
• MediaWiki\Revision\Slots
  • SlotRecord
  • 🔮 SlotRoleHandler – like ContentHandler but for slots
• MediaWiki\Page
  • ---- page storage and records
  • 🔮 PageStore – like RevisionStore but for the page table
  • 🔮 PageStoreFactory – for the same reason
  • 🔮 PageRecord – value class, I don't know if we'll need subclasses
  • 🔮 PageEventEmitter – like DerivedPageDataUpdater without all the extra stuff
  • 🔮 Probably some access-related exceptions
  • ---- page type handling
  • 🔮 PageTypeHandler
  • 🔮 PageTypeHandler subclasses
• MediaWiki\Edit
  • 🔮 EditController – logic for turning EditData into a RevisionRecord. Name kind of sucks.
  • 🔮 EditData – edit data to be turned into a RevisionRecord
  • 🔮 EditStash – cache mapping EditData to RenderedRevision
  • 🔮 Maybe some other class to have full-service methods like WikiPage::doEditContent(), if those don't wind up in EditController.
  • 🔮 Probably some exceptions
• (deprecate)
  • DerivedPageDataUpdater – main functionality in MediaWiki\Page\PageDataUpdater, state in MediaWiki\Edit\EditData, "preparing" in MediaWiki\Edit\EditController
  • PageUpdater – state in MediaWiki\Edit\EditData, creation of the RevisionRecord in MediaWiki\Edit\EditController, saving in MediaWiki\Page\PageStore
  • PageUpdateException – only used in PageUpdater
  • RevisionSlotsUpdate – now part of MediaWiki\Edit\EditData

Here MediaWiki\Revisions seems big like MediaWiki\Storage is now, but the difference is that there doesn't seem to be anything else to add to it in the future.

+1 to the use of MediaWiki\Edit, that was my intention when I originally introduced it, I just never completed the patch that would use it even more.

I like splitting Storage into a Revision namespace, though I'm not sure about the value in third namespace level (MediaWiki\Revision\Slots).

MediaWiki\Page looks reasonable as well, though it's harder to comment on that one since none of those classes exist yet :)

Slightly related, the new namespaces should use upper case directory names (like Storage did) to be in compliance with PSR-4 to begin with.

Change 461714 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Re-namespace RevisionStore and RevisionRecord classes

https://gerrit.wikimedia.org/r/461714

In T204158#4596757, @Legoktm wrote:

Slightly related, the new namespaces should use upper case directory names (like Storage did) to be in compliance with PSR-4 to begin with.

includes/page and includes/edit already exist.

I've argued elsewhere that we should use a new src directory as the PSR-4 root, to avoid exactly these kind of naming conflicts.

The new namespaces look fine to me (I don't think it matters much as people use autocomplete anyway, but they are certainly more intuitive than the old ones). How to split up / deprecate DerivedPageDataUpdater/PageUpdater/RevisionSlotsUpdate should be a separate discussion IMO, namespace-wise those are fine under Revision or Page.

Change 461714 merged by jenkins-bot:
[mediawiki/core@master] Re-namespace RevisionStore and RevisionRecord classes

https://gerrit.wikimedia.org/r/461714