[rfc][icedtea-web] immutbale transaltor

[Jie Kang]

Hello,

I think this patch is fine. Okay for me :)


On a side note:

I think at this point you can ditch the singleton pattern. I am pretty sure the existence of non-private constructors, even protected ones, invalidates the singleton pattern but this is kind of semantics. I mean, you could say a class with public constructors that's only ever instantiated once is a singleton then. I think an important concept to the singleton pattern is the compile-time guarantee that no instances outside of your singleton(s) will ever get instantiated.

Also, the singleton pattern by design is untestable, however the choice of use is cost-benefit. You gain the benefits of single instance with a compile-time guarantee among other things, with the costs of untestability, inability to subclass, etc. I think in general, you should really question any singleton use and try to avoid it as much as possible. If you want a testable singleton, it just doesn't really exist.

For why people use enums when they choose to create a singleton, it's really because it is simple and provides pretty much everything a singleton needs. A guarantee that there is only one instance, the ability to serialize without extra work, what's not to like? Apart from the fact that it's a singleton I guess.

I feel like you mean to ask, why do people use singletons, instead of why do people use enums for singletons :D


Regards,

----- Original Message -----
> Hi!
> 
> Attached patch is changing our new Transaltor to be immutable.
> 
> 
> The only desired change was to
> -    private ResourceBundle resources;
> +    private final ResourceBundle resources;
> 
> 
> and so .. get rid of loadResourceBundle, and so allow constructor chain of
>    Translator() {
>          this("net.sourceforge.jnlp.resources.Messages");
>      }
> 
>      Translator(String s) {
>              this(ResourceBundle.getBundle(s));
>          }
>      }
> 
>      Translator(ResourceBundle resources) {
>          this.resources = resources;
>      }
> 
> And so make it instantiatable and consequentially adapt the test....
> And so get rid of enum in favor of class, and so use handler idiom for
> creation....
> 
> 
> Personally,  why people use enums for singletons?!?!?! Well very simple
> singletons .. yes, but once
> there is some logic... Ouch they are so so *clumsy* ... So clamsy taht they
> can not be even properly
> tested ( no instance!, no overrload!). And once singleton is not
> immutbale.... Is it still singleton?
> 
> Afaik the state after the patch is better:
>   - singleton is still singleton
>   - newly:
>    -  initialized on demand
>    -  immutable
>    - the tets are done on separate copy, not on the changed singleton itself
>    (aaargh)
> 
> 
> Any comment why to keep enum welcomed....
> 
> 
> J.
> 

-- 

Jie Kang