Should we have a default label for COBranch?
qmathe opened this issue · comments
Currently COBranch.label can be nil when creating a new branch from scratch, but it cannot be nil when forking an existing branch with -makeBranchWithLabel:atRevision:.
I annotated the label property with nullable, but it may be better to set a default label like Default when creating a new branch from scratch.
When making a cheap copy, the new branch would be called 'Default' too, even when the parent branch isn't the default one in the parent persistent root.
Also if we set a default label, it should be localizable.
If we want to support scenarios where branches don't need to be given names by the user, it makes sense to keep it nullable.. which allows us to distinguish real labels chosen by the user from autogenerated default labels. We could add a -displayLabel that returns a non-null string.. if label is null, it could return a message like branch created at <time>.
ok, makes sense. I checked COPersistentRoot.name and it's not set by default either, so the behavior matches.
I also removed this TODO from COPersistentRoot.name: Rename to -displayName or -label to emphasize that this is the user-facing name? Let me know if you'd like to keep it. I can put it back in place.
Apple tends to use -displayName as a read-only property to provide a default user-facing name. So I wouldn't replace COPersistentRoot.name with COPersistentRoot.displayName.
For -label vs -displayName, the persistent root name should almost always be a user-picked name, while the branch label can be an internal name or a user-picked name depending on the application. Some app might use branches internally, but not expose them to the user, while others will let the user create branch explicitly. This is unlike persistent roots which are almost always representing objects/documents directly manipulated by the user.
btw I found an unused -displayName implementation in COBranch, so I tweaked it and exposed it in the public API. I also wrote the missing COPersistent.displayName counterpart. I'm not entirely convinced this is useful beside debugging, so I'm fine with removing these displayName properties. See 8918fdc