Re: questions about DateTime::Locale internal structure

2005-07-24 Thread Joshua Hoblitt
On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote:
   - Is there any reason why the locales are not singletons?

None that I can think of.

   - Can I make them singleton?

Locale objects are cached during 'load' so that the same object may be
shared between multiple DTs.  This cache gets dumped when: a new locale
is registered, an alias is added, an alias is removed.  So it may very
well be a win to make DateTime::Locale objects true singletons but you
probably won't notice a difference unless your screwing around with
custom locales.

You might want to seek Dave's opinion before putting effort into a
patch.

   - Can I make parameters like en_language, en_territory,
 en_complete_name, et al class variables, and do away with any instance
 variables?

That data needs to be unique per locale object.

Cheers,

-J

--


pgpYSgrjkgzy4.pgp
Description: PGP signature


Re: questions about DateTime::Locale internal structure

2005-07-24 Thread Daisuke Maki
Joshua Hoblitt wrote:
 On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote:
 
  - Is there any reason why the locales are not singletons?
 
 
 None that I can think of.
 
 
  - Can I make them singleton?
 
 
 Locale objects are cached during 'load' so that the same object may be
 shared between multiple DTs.  This cache gets dumped when: a new locale
 is registered, an alias is added, an alias is removed.  So it may very
 well be a win to make DateTime::Locale objects true singletons but you
 probably won't notice a difference unless your screwing around with
 custom locales.
 
 You might want to seek Dave's opinion before putting effort into a
 patch.
 
 
  - Can I make parameters like en_language, en_territory,
en_complete_name, et al class variables, and do away with any instance
variables?
 
 
 That data needs to be unique per locale object.

Not per locale class? The data currently resides in LocaleCatalog.pm,
which are then just register()ed at load time. they are used as
parameters to the Locale constructor, and I don't see them changing,
really.

What I'm really thinking here is that we can do away with DataForID and
shove everything to each class, so that a locale can initialize itself.

--d