Comment 0 for bug 98385

Status: Pending => Accepted

 Supporters added: chrism

Imagine that you have an ordered container with a custom name chooser.

OrderedContainerItemRenamer(container).renameItem(oldName, newName) uses IObjectMover to rename the item, and then restores up the item order. IObjectMover uses INameChooser to validate the new name. The name chooser is free to choose a name different from newName passed to it. If this happens, IObjectMover returns the real new name back to the item remover, which ignores it and tries to call container.updateOrder with a list of IDs that includes newName.

OrderedContainerItemRenamer should not assume that IObjectMover(container).moveTo(container, newName) will always return newName unchanged.

I would like to fix this bug, but it raises an API question. Is IContainerItemRenamer.renameItem(oldName, newName) allowed to rename the item at oldName to a name that is different from newName? If so, wouldn't it make sense for renameItem to return the real new name?

Options:

  1. renameItem should raise an error if the name chooser overrode newName to something else

  2. renameItem should cope with override new names and return the real new name

  3. renameItem should cope with override new names, but keep the old API (no return value) for backwards-compatibility raisins

I prefer option (2).