rtl::OUString searchAndReplace

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

rtl::OUString searchAndReplace

stephan.bergmann
Hi all,

<http://www.openoffice.org/issues/show_bug.cgi?id=66621> is a request to
add searchAndReplace functionality to rtl::OUString, giving the
following use case:  "Loading strings from a resource file [...] often
requires to replace certain parts of the loaded string with
runtime-dependent content.  For instance, a resource might contain an
error message string 'The object $object$ could not be found.', where
$object$ would be filled in at runtime."

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$").

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.

So, *is* there need for rtl::OUString searchAndReplace?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

bjoern.milcke
Hi Stephan,

> <http://www.openoffice.org/issues/show_bug.cgi?id=66621> is a request to
> add searchAndReplace functionality to rtl::OUString, giving the
> following use case:  "Loading strings from a resource file [...] often
> requires to replace certain parts of the loaded string with
> runtime-dependent content.  For instance, a resource might contain an
> error message string 'The object $object$ could not be found.', where
> $object$ would be filled in at runtime."
>
> 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$",I wouldn't want to d "$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$").
>
> 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.

+1

>
> So, *is* there need for rtl::OUString searchAndReplace?

IMO, no. Especially as I think we wanted to make the OUString const
anyway? AFAIK, the only method that modifies an OUString is operator+.
We should think about removing that and exploit the fact that OUStrings
can never change.

BTW, replacing strings in resources usually means using the tools String
rather than OUString, anyway. So, this would be another argument for an
external helper function that may be offered for both string types
(calling a single implementation).

Although I would vote for an easy-to-use interface. The typical case is
replacing one substring. For this I would like to write a single
(suitably short ;-) ) line of code.

-Bjoern

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
Bjoern Milcke wrote:

> Hi Stephan,
>
>> <http://www.openoffice.org/issues/show_bug.cgi?id=66621> is a request
>> to add searchAndReplace functionality to rtl::OUString, giving the
>> following use case:  "Loading strings from a resource file [...] often
>> requires to replace certain parts of the loaded string with
>> runtime-dependent content.  For instance, a resource might contain an
>> error message string 'The object $object$ could not be found.', where
>> $object$ would be filled in at runtime."
>>
>> 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$",I wouldn't
>> want to d "$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$").
>>
>> 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.
>
> +1
>
>>
>> So, *is* there need for rtl::OUString searchAndReplace?
>
> IMO, no. Especially as I think we wanted to make the OUString const
> anyway? AFAIK, the only method that modifies an OUString is operator+.
> We should think about removing that and exploit the fact that OUStrings
> can never change.

The hypothetical

   newStr = oldStr.searchAndReplace("$object$", whatever);

would leave oldStr unchanged (I did not mention that explicitly).

> BTW, replacing strings in resources usually means using the tools String
> rather than OUString, anyway. So, this would be another argument for an
> external helper function that may be offered for both string types
> (calling a single implementation).
>
> Although I would vote for an easy-to-use interface. The typical case is
> replacing one substring. For this I would like to write a single
> (suitably short ;-) ) line of code.

...which is probably hampered by the fact that there is not a single
(well-engineered, see above) convention for such placeholders in
resource strings, but various different ones.

O overall OOo architecture, where art thou?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

bjoern.milcke
In reply to this post by stephan.bergmann
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:
>>> [...]
>>> So, *is* there need for rtl::OUString searchAndReplace?
>>
>> IMO, no. Especially as I think we wanted to make the OUString const
>> anyway? AFAIK, the only method that modifies an OUString is operator+.
>> We should think about removing that and exploit the fact that
>> OUStrings can never change.
>
> The hypothetical
>
>   newStr = oldStr.searchAndReplace("$object$", whatever);
>
> would leave oldStr unchanged (I did not mention that explicitly).

Sorry, stupid me. Although you didin't mention it, it is quite obvious.
I was mislead by the word "replace".

>> BTW, replacing strings in resources usually means using the tools
>> String rather than OUString, anyway. So, this would be another
>> argument for an external helper function that may be offered for both
>> string types (calling a single implementation).
>>
>> Although I would vote for an easy-to-use interface. The typical case
>> is replacing one substring. For this I would like to write a single
>> (suitably short ;-) ) line of code.
>
> ...which is probably hampered by the fact that there is not a single
> (well-engineered, see above) convention for such placeholders in
> resource strings, but various different ones.

Well, maybe we should decide about a common convention for this. I don't
know if it is wise to open the discussion on this topic again, and at
this place, but I think it would make sense to have a common style
especially for translators.

My last information about recommendations for placeholders is to use
%PLACEHOLDER which I consider worse than the $(PLACEHOLDER) I used
before, because the boundaries of the variable name are clearer. (the
expression "$(FOO)bar" would be %FOObar in the other style, which is
ambiguous. Well, also not very common, though.)

But, OTOH do we really need the function to take care of the format of
variables? We don't want a grammar parser, just replacing strings. And I
don't consider the case of quoted strings that look like variables a use
case. Are there examples for this?

(Usually I have something like "%OBJECT is selected" where "is selected"
is translated. And I don't think this phrase will be translated into
"%OBJECT" in any language on the world).


Imagine this piece of code:

  // replace number
  OUString aResString( String( ::chart::ResId( STR_MYRESSTR )));
  const OUString aReplacementStr( RTL_CONSTASCII_USTRINGPARAM("%NUM"));

with this code replacing the variable:

  // current solution
  sal_Int32 nIndex = aResString.indexOf( aReplacementStr );
  if( nIndex != -1 )
      aResult = String( aResString.replaceAt(
                            nIndex, aReplacementStr.getLength(),
                            String::CreateFromInt32( nMyNumber )));

It would be nice to have this, at least as a first step:

  // better solution
  aResult = ::some_namespace::replaceString(
      aResString, aReplacementStr, String::CreateFromInt32( nMyNumber ));

I don't think we need to have this as a method at the OUString (the
interface is already quite big).

Or maybe

  bool bDidWork = ::some_namespace::replaceString(
      aResString, aReplacementStr, String::CreateFromInt32( nMyNumber ));

which gets aResString as an in/out parameter and returns if the
replacement was successful. But I don't know what you would usually want
to do in case this does not work. Well, mabye an assertion violation
message.

* Would it help to allow passing just "NUM" in the example and the
helper adds the "%" or "$(" / ")" ? I don't think so.

* Would it be necessary to replace more than one variable at once? I
also don't think so.

* Is it a requirement to avoid replacing a quoted phrase that is no
variable but only look like one?

So, keep it simple.

(In contrast to this mail, sorry ;-) )

-Bjoern

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

Bernd Eilers
In reply to this post by stephan.bergmann

Hi there!

Just two possibly incompatible thoughts on that:

1.) What about using regular expressions like you can do in java or perl
  with the search string being a regular expression and the replacement
String having the possibility to contain /$1 /$2 /$3 etc. with the
meaning to replace with the match found for the n-th group surrounded by
brackets inside the regular expression?

The Boost library which AFAIK we already use for something else does
contain support for regular expressions.

Have a look at:

http://www.boost.org/libs/regex/doc/index.html
http://www.boost.org/libs/regex/doc/non_standard_strings.html


2.) What about using arrays of Strings as arguments instead of just
Strings? This would be adding the possiblity to replace multiple
patterns at the same time while eliminating your problem one mentioned
as well. And it will likely be faster than multiple calls to one replace
method with different patterns and replacements.


Kind regards,
Bernd Eilers


Stephan Bergmann wrote:

> Bjoern Milcke wrote:
>> Hi Stephan,
>>
>>> <http://www.openoffice.org/issues/show_bug.cgi?id=66621> is a request
>>> to add searchAndReplace functionality to rtl::OUString, giving the
>>> following use case:  "Loading strings from a resource file [...]
>>> often requires to replace certain parts of the loaded string with
>>> runtime-dependent content.  For instance, a resource might contain an
>>> error message string 'The object $object$ could not be found.', where
>>> $object$ would be filled in at runtime."
>>>
>>> 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$",I wouldn't
>>> want to d "$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$").
>>>
>>> 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.
>>
>> +1
>>
>>>
>>> So, *is* there need for rtl::OUString searchAndReplace?
>>
>> IMO, no. Especially as I think we wanted to make the OUString const
>> anyway? AFAIK, the only method that modifies an OUString is operator+.
>> We should think about removing that and exploit the fact that
>> OUStrings can never change.
>
> The hypothetical
>
>   newStr = oldStr.searchAndReplace("$object$", whatever);
>
> would leave oldStr unchanged (I did not mention that explicitly).
>
>> BTW, replacing strings in resources usually means using the tools
>> String rather than OUString, anyway. So, this would be another
>> argument for an external helper function that may be offered for both
>> string types (calling a single implementation).
>>
>> Although I would vote for an easy-to-use interface. The typical case
>> is replacing one substring. For this I would like to write a single
>> (suitably short ;-) ) line of code.
>
> ...which is probably hampered by the fact that there is not a single
> (well-engineered, see above) convention for such placeholders in
> resource strings, but various different ones.
>
> O overall OOo architecture, where art thou?
>
> -Stephan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
In reply to this post by stephan.bergmann
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.

(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.)

> 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.

> 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).

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
In reply to this post by bjoern.milcke
Hi Bjoern,

> BTW, replacing strings in resources usually means using the tools String
> rather than OUString, anyway.

http://api.openoffice.org/docs/common/ref/com/sun/star/resource/OfficeResourceLoader.html

Welcome to the modern world ;)

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
In reply to this post by bjoern.milcke
Hi Bjoern,

>   // better solution
>   aResult = ::some_namespace::replaceString(
>       aResString, aReplacementStr, String::CreateFromInt32( nMyNumber ));
>
> I don't think we need to have this as a method at the OUString (the
> interface is already quite big).

Well, whether this is part of the OUString class, or in some external
helper namespace/class, is a matter of taste, religion, and other things
hard to debate about ;)

Personally, I'd prefer to have a OUString member, but that might be only
me. I'd buy the OUString-external helper, too.


On the other hand ... replacement might be cheaper (yes, I'm doing
optimizations here before I proved I need them - which of our coding
guideline items is viloted here?) if it can be done in-place. That could
save those costly memory allocations, at least somtimes. (Which, btw. is
a reason why I don't like OUString's constness-paradigmn.)

Which would mean we should have the functionality at the OUStringBuffer.
Would also be nice to have, but then Stephan should be prepared for me
submitting RFEs for the OUStringBuffer usability :)

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
Bernd Eilers wrote:

>
> Hi there!
>
> Just two possibly incompatible thoughts on that:
>
> 1.) What about using regular expressions like you can do in java or perl
>  with the search string being a regular expression and the replacement
> String having the possibility to contain /$1 /$2 /$3 etc. with the
> meaning to replace with the match found for the n-th group surrounded by
> brackets inside the regular expression?

Not sure how that relates to the problem of replacing placeholders in a
fixed text with dynamic content.

> The Boost library which AFAIK we already use for something else does
> contain support for regular expressions.
>
> Have a look at:
>
> http://www.boost.org/libs/regex/doc/index.html
> http://www.boost.org/libs/regex/doc/non_standard_strings.html
>
>
> 2.) What about using arrays of Strings as arguments instead of just
> Strings? This would be adding the possiblity to replace multiple
> patterns at the same time while eliminating your problem one mentioned
> as well. And it will likely be faster than multiple calls to one replace
> method with different patterns and replacements.
>
>
> Kind regards,
> Bernd Eilers

Yes, functionality to solve the above problem ("replacing placeholders
in a fixed text with dynamic content") would probably use some sort of
dictionary to map different placeholders to actual content, and do the
complete conversion in one call.  But that is somewhat off topic; all I
wanted this thread for is to argue that adding some searchAndReplace to
rtl::OUString is probably not as useful as it might appear at first
sight.  How the functionality really asked for in the corresponding
issue should be implemented is worth another thread.

-Stephan

[...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
In reply to this post by stephan.bergmann
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         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

bjoern.milcke
In reply to this post by stephan.bergmann
Hi Frank, Stephan

> Hi Bjoern,
>
>> BTW, replacing strings in resources usually means using the tools String
>> rather than OUString, anyway.
>
> http://api.openoffice.org/docs/common/ref/com/sun/star/resource/OfficeResourceLoader.html
>
> Welcome to the modern world ;)

Nice to have this, however I never used it, and still I have similar
code to yours just using the tools string rather than OUString. (Can the
OfficeResourceLoader using UNO API be used to fill an SfxTabDialog? And
if so, how?)


If OUString::replaceString is const (as suggested), there is no real
difference in usage compared to an external function (only difference
would be passing the string in question as parameter, right? Or did I
miss something?). I would vote for using an external function.

I second Stephan's concerns, that creating a new method at OUString and
later changing it is not a good idea. Having a separate function is the
better approach, because this way you can make clear that the function
is only for resource-string replacement. (You won't want to add a method
to OUString called replaceResourceStringVariable or the like).

I suppose we are not the only people in the world wanting to replace a
string in another string. If we want a well-designed full-featured
facility to robustly replace strings in any situation, I reckon we could
evaluate using some existing library. Of course the library would have
to be flexible enough to adapt it to our somewhat proprietary string
implementations. But I think such a solution might be worth giving a try.

So: either make a simple feasible solution like "just replace a string",
or use an existing library that has already fixed "all the" bugs that
might appear when creating a flexible fail-safe token-based replacement
tool, and write a wrapper around it to offer the same simple usage than
with the other solution.

(Because we want to replace repeated multiple lines of code by simple
one-line code and not make it more fail-safe and add more lines).

-Bjoern

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
Hi Bjoern,

> Nice to have this, however I never used it, and still I have similar
> code to yours just using the tools string rather than OUString. (Can the
> OfficeResourceLoader using UNO API be used to fill an SfxTabDialog? And
> if so, how?)

Sorry, I don't get you here.
The OfficeResourceLoader is able to load a string from a .res file -
nothing more, nothing less. You can use it anywhere you like ...

> I second Stephan's concerns, that creating a new method at OUString and
> later changing it is not a good idea.

I never suggested changing it later. I'd suggest creating a new method
with extended functionality if we really need it.
replaceString would be a low-level functionality which can be used to
implement more complex patterns.

> Having a separate function is the
> better approach, because this way you can make clear that the function
> is only for resource-string replacement. (You won't want to add a method
> to OUString called replaceResourceStringVariable or the like).

Well, it is not for resource-string replacement. It is for replacing
strings in other strings. People can *use* it for resource string
replacements, if they know that the caveats pointed out by Stephan do
not apply.


> I suppose we are not the only people in the world wanting to replace a
> string in another string. If we want a well-designed full-featured
> facility to robustly replace strings in any situation,

That's what I'm trying to say: I'm not sure we want, since I'm not sure
we need.


> So: either make a simple feasible solution like "just replace a string",

+1

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

Carsten Driesner
In reply to this post by stephan.bergmann
Frank Schönheit - Sun Microsystems Germany schrieb:

>
> Well, it is not for resource-string replacement. It is for replacing
> strings in other strings. People can *use* it for resource string
> replacements, if they know that the caveats pointed out by Stephan do
> not apply.
>
>
>> I suppose we are not the only people in the world wanting to replace a
>> string in another string. If we want a well-designed full-featured
>> facility to robustly replace strings in any situation,
>
> That's what I'm trying to say: I'm not sure we want, since I'm not sure
> we need.
>
>
>> So: either make a simple feasible solution like "just replace a string",
+1

I am also looking forward to a SIMPLE function that just replaces a
string in a string.

Regards,
Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
Carsten Driesner wrote:

> Frank Schönheit - Sun Microsystems Germany schrieb:
>>
>> Well, it is not for resource-string replacement. It is for replacing
>> strings in other strings. People can *use* it for resource string
>> replacements, if they know that the caveats pointed out by Stephan do
>> not apply.
>>
>>
>>> I suppose we are not the only people in the world wanting to replace
>>> a string in another string. If we want a well-designed full-featured
>>> facility to robustly replace strings in any situation,
>>
>> That's what I'm trying to say: I'm not sure we want, since I'm not sure
>> we need.
>>
>>
>>> So: either make a simple feasible solution like "just replace a string",
> +1
>
> I am also looking forward to a SIMPLE function that just replaces a
> string in a string.

Ha!  New customer.  :)  But please be precise:

Does anybody have demand for "replac[ing] a string in a string"
*outside* the area of resource strings?

If no, I suggest we do the following:  Clean up the OOo resource strings
so that they use a single, unambiguous syntax for dynamic tokens and
introduce (C++ or UNO) functionality to expand any dynamic tokens that
is easy to use (esp. for the general case of replacing zero or one
dynamic token).

If yes, I will happily add some rtl::OUString searchAndReplace.  But we
should do the above nonetheless, shouldn't we?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
Hi Stephan,

> If no, I suggest we do the following:  Clean up the OOo resource strings
> so that they use a single, unambiguous syntax for dynamic tokens and
> introduce (C++ or UNO) functionality to expand any dynamic tokens that
> is easy to use (esp. for the general case of replacing zero or one
> dynamic token).
>
> If yes, I will happily add some rtl::OUString searchAndReplace.  But we
> should do the above nonetheless, shouldn't we?

We don't have a real-life problem with the current resource string
replacement, and it's simply not worth the huge effort to touch all our
resource strings. It will break more code that it will fix bugs.

If we really don't know what to do next, then there's bigger fish to
catch than this, for sure. We should not fix a problem which does not exist.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

frank.schoenheit
In reply to this post by stephan.bergmann
Hi Stephan,

> Does anybody have demand for "replac[ing] a string in a string"
> *outside* the area of resource strings?

That's the wrong question. If we're serious about replacing the
tools-String class with the rtl-OUString, then it's ridiculous to *not*
have a plain string replacement functionality (intern or extern to the
class, I do not really care).

Look around in our code how often String is used instead of OUString,
even in newly written code. That's not only because of existing
interfaces require Strings, but also because string manipulation is so
much easier with the String.

If we do not have such very basic operations on the OUString, then
people will never accept it as replacement.

That said, I'm out of this discussion (well, I try to be). I've said
everything which reasonably can be said here.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: rtl::OUString searchAndReplace

stephan.bergmann
In reply to this post by stephan.bergmann
Stephan Bergmann wrote:

> Carsten Driesner wrote:
>> Frank Schönheit - Sun Microsystems Germany schrieb:
>>>
>>> Well, it is not for resource-string replacement. It is for replacing
>>> strings in other strings. People can *use* it for resource string
>>> replacements, if they know that the caveats pointed out by Stephan do
>>> not apply.
>>>
>>>
>>>> I suppose we are not the only people in the world wanting to replace
>>>> a string in another string. If we want a well-designed full-featured
>>>> facility to robustly replace strings in any situation,
>>>
>>> That's what I'm trying to say: I'm not sure we want, since I'm not sure
>>> we need.
>>>
>>>
>>>> So: either make a simple feasible solution like "just replace a
>>>> string",
>> +1
>>
>> I am also looking forward to a SIMPLE function that just replaces a
>> string in a string.
>
> Ha!  New customer.  :)  But please be precise:
>
> Does anybody have demand for "replac[ing] a string in a string"
> *outside* the area of resource strings?
>
> If no, I suggest we do the following:  Clean up the OOo resource strings
> so that they use a single, unambiguous syntax for dynamic tokens and
> introduce (C++ or UNO) functionality to expand any dynamic tokens that
> is easy to use (esp. for the general case of replacing zero or one
> dynamic token).
>
> If yes, I will happily add some rtl::OUString searchAndReplace.  But we
> should do the above nonetheless, shouldn't we?
>
> -Stephan

I did not hear anything new, but decided to add some
comphelper::string::searchAndReplace (see over at interface-anounce).
Use it for whatever you like.  :)  (And if it becomes clear that we do
not need it we can drop it again, as it is not published URE API.)  And
still, somebody might be interested in cleaning up the resource syntax mess?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]