You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@kc.rr.com> on 2006/09/11 04:42:02 UTC
[classlib][i18n] Messages code comments
Is there any reason that there are three overloaded getString(String, XXX)
methods that take variations of Object?
Can't we just condense this into one method?
public static String getString(String key, Object. args)
In fact, this signature allows for the getString(String) method to be
removed as well, since a vararg argument can be omitted altogether.
Additionally, I would change the format method to use a vararg as well.
Also, I'd argue that there's little value in having the overloaded methods
that take an 'int' and a 'char'. I'd suggest just letting autoboxing handle
this in conjunction with the varargs.
Where is the code generator for these classes located?
-Nathan
Re: [classlib][i18n] Messages code comments
Posted by Tim Ellison <t....@gmail.com>.
Ilya Okomin wrote:
> Hello, Nathan!
>
> Thank you for taking a deep look at the i18n task!!
> I try to comment inline...
>
> On 9/11/06, Nathan Beyer <nb...@kc.rr.com> wrote:
>>
>> Is there any reason that there are three overloaded getString(String,
>> XXX)
>> methods that take variations of Object?
>
> Actually, source code for the Messages class was taken (it was discussed at
> the threads of internationalization issues) from the existing
> o.a.h.luni.util.Msg and o.a.h.luni.util.MsgHelp classes.
> I'm not the author of mentioned classses but I assume that three overloaded
> getString() methods were designed to increase performance of the common
> used
> messages calls.
The original code came from a 1.4 codebase, before varargs/autoboxing.
> Can't we just condense this into one method?
>>
>> public static String getString(String key, Object. args)
>
> I worried for the performance, however, I ran several small tests with
> existing Messages implementation and with Java 5.0 variable arguments
> feature usage and didn't see the big difference in performance. Condensing
> all these methods in one seems to me a good idea.
Should all be eaten by the compiler, so combining into a single method
should be fine.
>> In fact, this signature allows for the getString(String) method to be
>> removed as well, since a vararg argument can be omitted altogether.
>> Additionally, I would change the format method to use a vararg as well.
>
>
> All enhancements are welcomed!!
>
>> Also, I'd argue that there's little value in having the overloaded methods
>> that take an 'int' and a 'char'. I'd suggest just letting autoboxing
>> handle
>> this in conjunction with the varargs.
>
> Where is the code generator for these classes located?
>
> Take a look at the HARMONY-1041issue, all sources for the i18n classes
> generator are available there.
> If you want to improve Messages class code - you just need to modify
> Messages template file.
Give me a while to get the tool code into svn then you can modify the
template code and we'll re-generate the .java files.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][i18n] Messages code comments
Posted by Ilya Okomin <il...@gmail.com>.
Hello, Nathan!
Thank you for taking a deep look at the i18n task!!
I try to comment inline...
On 9/11/06, Nathan Beyer <nb...@kc.rr.com> wrote:
>
> Is there any reason that there are three overloaded getString(String, XXX)
> methods that take variations of Object?
Actually, source code for the Messages class was taken (it was discussed at
the threads of internationalization issues) from the existing
o.a.h.luni.util.Msg and o.a.h.luni.util.MsgHelp classes.
I'm not the author of mentioned classses but I assume that three overloaded
getString() methods were designed to increase performance of the common used
messages calls.
Can't we just condense this into one method?
>
>
>
> public static String getString(String key, Object. args)
I worried for the performance, however, I ran several small tests with
existing Messages implementation and with Java 5.0 variable arguments
feature usage and didn't see the big difference in performance. Condensing
all these methods in one seems to me a good idea.
In fact, this signature allows for the getString(String) method to be
> removed as well, since a vararg argument can be omitted altogether.
> Additionally, I would change the format method to use a vararg as well.
All enhancements are welcomed!!
Also, I'd argue that there's little value in having the overloaded methods
> that take an 'int' and a 'char'. I'd suggest just letting autoboxing
> handle
> this in conjunction with the varargs.
Where is the code generator for these classes located?
Take a look at the HARMONY-1041issue, all sources for the i18n classes
generator are available there.
If you want to improve Messages class code - you just need to modify
Messages template file.
Regards,
Ilya.
-Nathan
--
--
Ilya Okomin
Intel Middleware Products Division
Re: [classlib][i18n] Messages code comments
Posted by Tony Wu <wu...@gmail.com>.
+1 to condense them into getString(String, Ojbect) by autoboxing.
And the getString(String,Object,Object) method can work with primitive
arguments also.
On 9/11/06, Nathan Beyer <nb...@kc.rr.com> wrote:
> Is there any reason that there are three overloaded getString(String, XXX)
> methods that take variations of Object?
>
>
>
> Can't we just condense this into one method?
>
>
>
> public static String getString(String key, Object. args)
>
>
>
> In fact, this signature allows for the getString(String) method to be
> removed as well, since a vararg argument can be omitted altogether.
> Additionally, I would change the format method to use a vararg as well.
>
>
>
> Also, I'd argue that there's little value in having the overloaded methods
> that take an 'int' and a 'char'. I'd suggest just letting autoboxing handle
> this in conjunction with the varargs.
>
>
>
> Where is the code generator for these classes located?
>
>
>
> -Nathan
>
>
>
--
Tony Wu
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org