geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 20 Aug 2003 20:44:50 GMT
On Wednesday, Aug 20, 2003, at 14:48 Europe/London, Cabrera, Alan wrote:

>> -----Original Message-----
>> From: Alex.Blewitt@ioshq.com [mailto:Alex.Blewitt@ioshq.com]
>>
>> class Logger {
>>   Writer out;
>>   logString pattern, int i) {
>>     //parsepattern
>>     StringBuffer buffer = new StringBuffer();
>>     buffer.add(firstPartOfPattern);
>>     buffer.add(String.valueOf(i));
>>     buffer.add(secondPartOfPattern);
>>     out.write(buffer.toString());
>>     out.writeln();
>>   }
>> }
>>
>> class Logger {
>>   Writer out;
>>   logString pattern, int i) {
>>     //parsepattern
>>     out.write(firstPartOfPattern);
>>     out.write(String.valueOf(i));
>>     out.write(secondPartOfPattern);
>>     out.writeln();
>>   }
>> }
>
> The devil is in the details, here "parsepattern".  How is that better 
> than
> using the existing i18n formatter?

My point was not the parse pattern itself; you'll note that in both 
examples it's there. What my point was is that there's very little 
point in building it up in memory using a StringBuffer, only to then 
write out the string as a whole, when you can write out the individual 
parts to the stream and get the concatenation for free.

IIRC the Java text classes parse the pattern and then build a string 
internally as a StringBuffer, then convert it to the string all in one 
go. My point was that it would be possible to write a log method that 
did not do that, but instead wrote it out to a stream in one go.

I can provide demo code if I'm not making the point clear :-)

Alex.


Mime
View raw message