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.
>> (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.
>>> 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.
I, for myself, will almost never (up to really never) need this
additional functionality.
> 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?
> 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.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
