yuja added inline comments.
INLINE COMMENTS
> martinvonz wrote in state.py:84
> Oh, and I should clarify that I think the root of the problem is that you're
> mixing the class for reading with state itself (but only the top-level items
> of it). Let's say someone realizes they want to iterate over the items in the
> state, would we also add a .items() then? (I don't think that's a likely
> scenario, but it shows what I mean.)
Sorry if it's already discussed, but what's the benefit of `cmdstate`
not being a plain dict?
I think plain load/save functions are much simpler than a dict-like object
backed by file, i.e.
state = statemod.load(repo, fname)
state = {'version': 1, 'nodes': nodelines}
statemod.save(repo, fname, state)
(statemod.load/save could be a class for serialization/deserialization)
The state dict would be wrapped anyway depending on application logic.
If we can find out a common behavior between "state"s, we can extract it to a
state class,
but that will still be separated from the storage format.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D2593
To: pulkit, #hg-reviewers
Cc: yuja, martinvonz, indygreg, durin42, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
