harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] internationalization
Date Wed, 12 Jul 2006 23:31:39 GMT


Alexey Petrenko wrote:
> Geir,
> 
> I've reread your email in the morning :)
> 
> Internationalization classes auto-generation is really good idea. We
> can apply it for method described here and for "new Eclipse" method.

I'll settle for it being "an idea".  Not sure if it's a good one.   Tim
has been working in this area, and I'm interested to hear what he thinks.

> 
> In the first case "generator" will insert correct resource bundle and
> package name. In the second one we can generate the supporting class
> from the resource bundle file.
> 
> There will be 2 big differences between this two methods:
> 1. Initialization time: much faster for the "first" method
> 2. Run time access time: much faster for the "second" method
> 
> So if we will have situation with the big resource file and small
> number of accesses to it then the "first" method will be faster. In
> the case with large number of accesses the "second" method will be
> more preferable.

Can you quantify what "much faster" is for both cases?

> 
> Probably we should think about using both methods depends on the purpose.
> 
> For example. For UI application we have a huge number of messages
> which are widely used during normal run (menu items, user messages
> etc) and in this case the "second" method seems better.
> Otherwise for the code without user interaction the messages from the
> bundle will be mostly used as error messages for the throwing
> exceptions. We hope that exceptions will not happen very often. And we
> know that throwing an exception is rather long operation. So in this
> case the "first" method seems better.
> 
> Hmm... It looks like I've found an argument for using traditional
> method in class library :)

:)

> 
> SY, Alexey
> 
> 2006/7/11, Geir Magnusson Jr <geir@pobox.com>:
>>
>>
>> Tim Ellison wrote:
>> > Ilya Okomin wrote:
>> >> I'd like to be a volunteer for that.
>> >
>> > I just started working in this area (for SQL), maybe that is what
>> > prompted you...<g>
>> >
>> >> IMHO it's reasonable to use framework presented in luni module with
>> some
>> >> modifications.
>> >> To avoid duplication of Msg class I'd suggest use slightly modified
>> Msg
>> >> class named let say
>> >> o.a.h.luni.utils.ExtMsg.
>> >> ExtMsg has the same methods as Msg, the difference is only these
>> methods
>> >> are
>> >> non static,
>> >> also specific external messages resource bundle will be initialized
>> by name
>> >> in the constructor.
>> >> Each module will have class o.a.h.<module>.MsgUtils with static
>> field 'msg'
>> >> that is the instance of ExtMsg
>> >> initialized with the name of the external messages resource bundle
>> related
>> >> to this module.
>> >> Thus external message for e.g. security module could be obtained
>> using next
>> >> call:
>> >>
>> >>
>> "org.apache.harmony.security.internal.MsgUtils.msg.getString("security.1");"
>>
>> >
>> > I see your point, and considered doing it that way too.  I'm not overly
>> > concerned about the duplication, they are trivial helper methods
>> anyway,
>> > and we all know that singletons are evil ;-)
>>
>> I don't understand this, given you have one...
>>
>> >
>> >> And at last, place to keep resources with external messages I
>> suppose to be
>> >> o.a.h.<module>.internal.
>> >
>> > I went for o.a.h.<module>.internal.nls just to keep them tidy.
>> >
>> >> If all these thoughts sounds reasonable, I'd like to implement
>> framework
>> >> mentioned above and send you a patch.
>> >
>> > The real work is going through and externalizing all the messages, and
>> > if I were to be really ambitious to add messages to all the exceptions
>> > that we throw that don't have anything right now.
>> >
>> > Patches are always welcome.  We can work on that that as we finalize on
>> > the framework.
>>
>> Have you had any thoughts about a 'common' code set, that is copied and
>> modified at build time, setting the right package name and bundle name
>> by convention?  That would remove the need to duplicate the code.
>>
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
> 
> 

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


Mime
View raw message