Comment 10 for bug 98311

I pushed a branch with a failing test in one revision, and what I believe is a fairly clear implementation of the aforementioned proposed and agreed upon change in behaviour. I would like to discuss this, as the test currently fails, among other concerns I'll express further..

Two major concerns:

  (a) Though it seems worthwhile to pass the newly copied object to INameChooser from ObjectCopier, rather than the original, the test has to 'mark' the object, a modification, which I agree shouldn't be the work done by INameChooser.

  (b) The test still fails with the proposed change included. My test assigns an arbitrary attribute, and this seems as if it should be fine, though not a recommended way of storing values, simply to mark this object. If I'm wrong, I apologize for the oversight. Perhaps directlyProvides for a marker would be a better way?

My general concern is, in order for this test to verify the behaviour is changed, it must modify the newly copied object in a name chooser, which is recommended against, and a test may suggest that it is 'supported' behaviour.

That said, I still believe it is sensible for this order of operations to change. No existing tests fail, but my test doesn't pass, and I'm not sure it's a test which, other than showing this change enacted a change, tests functionality which should be supported.

My greater question after working a bit with this problem is, other than past API compatibility, is there a compelling reason for a NameChooser to have a copy of either object? Its' job seems to be to check if the requested name exists in the current container, and to return an alternative if so, or to handle formatting issues like turning spaces into dashes or underscores.

I can see why, from a holistic perspective, it may have made sense early in Z3/ZTK design to include the object here, I just wonder if any practical uses of this have emerged.