Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
Now, being the pain in the neck that I am, I wonder whether solving the
above via a hypothetic
newStr = oldStr.searchAndReplace("$object$", whatever);
would generally be useful. In general, some searchAndReplace would not
work at least in the following two scenarios:
1 When there is more than one token (e.g., "$object1$", "$object2$",
...) to replace in oldStr, and the replacements may contain text that
looks like one of the tokens (but must not be replaced).
2 When there is an escape mechanism so that oldStr can contain text
that looks like a token but is not replaced with a token (e.g.,
"\$object1$" would not expand to "\"+whatever, but to verbatim "$object1$").
Well, both cases are possible in theory, but extremely unlikely to
happen in practise. Bjoern already outline this for 1. For 2., I could
simply say that the replacement mechanism used here is used in our
resource files for agres, and I never heard of such a problem.
Why go for "extremely unlikely" when you can have "cannot happen, by
design," when all the latter takes is a little thinking in the design phase?
(Another argument for 1. not holding is that such cases are of course
simply in the responsibility of the string writer, and should not be of
concern for our string API.)
Hu? "The file %1 cannot be opened due to internal error %2."
searchAndReplace("$1", "/some/%2/weird/filename");
searchAndReplace("$2", "-12345");
-> "The file /some/-12345/weird/filename cannot..."
Who's to blame?
IMO, a well-engineered framework to replace parts of resource strings
with dynamic content would allow for both multiple tokens and an escape
mechanism, so could not use the hypothetic rtl::OUString searchAndReplace.
Sure. Let's also make this well-engineered framework cook coffee, while
we are at it.
Nonsense. Make it do one thing. But make it do it right.
So, *is* there need for rtl::OUString searchAndReplace?
Yes. I typed the code for it quite some times in different projects,
whose only common denominator is, say, comphelper. So, I could either
add some string helper functionality to comphelper (which would be kind
of stupid), to the UDK (which is what I asked you to do in the issue :),
or continue coding the thing again and again (which is what I'm doing
right now, but this of course is unsatisfying).
My point is that I think the code you typed multiple times is wrong.
So, rather than add a function of dubious functionality to
rtl::OUString, I would rather want to spend efforts designing a working
resource framework.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
