Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
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?
Because the smaller solution might be sufficient for practical needs,
and the bigger and complete one could be created when necessary.
For one, I do not think that one is any bigger than the other. For
another, the problem with that approach is that rtl::OUString is
published API, so the cost of adding something now that is later
obsoleted by something else is quite high. Thats why I give all this a
second thought before enthusiastically storming ahead and adding that
trivial little searchAndReplace...
(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?
Hmm. The one who used %1 instead of $1$? :)
Okay, I see your point. On the other hand, I still think the question
is: Is it worth it? How many such bugs have we seen in the past 15 years
(which is how long we're using the current mechanism), compared to how
many effort would it take to design/implement a complete solution,
compared to what would be the runtime overhead of the complete solution?
I like the KISS principle, somehow.
I would consider correctness (even if only of borderline practical
relevance) more important than alleged simplicity here. (Neither the
calling interface nor the implementation of a function to "replace
multiple strings and de-escape" need be any more complicated than of a
function to "replace a single string.")
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.
Sure. Let's replace it a single occurance of a sub string with another
string.
*If* you have strings that have multiple placeholders, and *if* they're
likely (or even only possible) to needs substitutes which in turn
contain the placeholder pattern, *then* (and not earlier) implement code
on the top of the existing code, which cares for your special concerns.
Why the "likely"? Why write broken code?
I, for myself, will almost never (up to really never) need this
additional functionality.
You do not know whether the translators of your strings need the escape
feature.
My point is that I think the code you typed multiple times is wrong.
No.
"The $object$ could not be opened.", $object$ being "table" or "query".
What's wrong about this?
OK, let me rephrase: I am concerned with adding a function to
rtl::OUString that is of use in only some places, when there is also
need for a more general function, anyway.
So, rather than add a function of dubious functionality to
rtl::OUString, I would rather want to spend efforts designing a working
resource framework.
I would want to have functionality which, in a clear and usable way,
does what I need. Not functionality which can do everything which I
might need over the next ten years, if it is possible to add this
additional functionality later.
Having said all this where I couldn't resists somehow ... In general I
agree to that a well-designed framework which cares for future needs is
worth additional effort in the design phase. I just think that providing
basic search-and-replace functionality which can be extended in the
future doesn't violate this.
The cheap extensibility in the future is what I think is not given here:
For one, as I already mentioned, rtl::OUString is stable API that we
should only touch with care.
For another, as I also already mentioned, the translators might someday
need the escape feature, at which point you need to find and fix all the
uses of those strings in the code for which the escape feature is needed.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
