Re: rtl::OUString searchAndReplace

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: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org