[Catalyst] Re: using Plugin::Singleton and testing

[A. Pagaltzis]

* Daniel McBrearty <danielmcbrearty at gmail.com> [2006-11-17 22:30]:
> On 11/17/06, A. Pagaltzis <pagaltzis at gmx.de> wrote:
>>* Daniel McBrearty <danielmcbrearty at gmail.com> [2006-11-17 12:00]:
>>> A global is something that is in the global namespace.
>>> A singleton isn't, any more than other class is. You have to
>>> import the class to which it belongs to use it.
>>
>> That might be true in Java. It's patently false in Perl.
> 
> (file MySingleton.pm)
> package MySingleton;
> 
> ...
> 
> sub get_instance {
> # the standard stuff ...
> }
> 
> 1;
> 
> 
> (EOF)
> 
> please explain how it is possible to get hold of this object
> without doing
> 
> use MySingleton;
> 
> my $s = MySinglton->get_instance;
> 
> (assuming that you don't deliberately export into the global
> namespace, which can be the case with any class)

If you do `use MySingleton` in any part of the code, it’s
possible to say `MySingleton->get_instance` in any other part.
In Java, this is not so.

>>> Until someone actually presents a solid reason why you should
>>> *never* have a class which can only have a single instance,
>>> the argument is going nowhere, as far as I can see.
>> 
>> No, I think the onus is the other way around. I'd like to hear
>> about a case that is much more sensibly be solved using
>> a singleton class rather than by other means of ensuring
>> uniqueness in a higher level of the infrastructure.
>> 
>> I don't want to claim that there is no circumstance in which
>> singletons are useful; I argue with people who claim that
>> every use of GOTO is evil, too. But I doubt that singletons
>> are even as useful as GOTO, in practice.
> 
> So my original example : say we have an application that
> streams audio, and only one source may be streamed at a time.
> Having more than one player instance in existence could violate
> this on many OS's. Even if the OS would cause an error  (due to
> more the resource being busy when it starts up), you just don't
> want it to happen. How would you design this?

How many times have I said this? By putting the player instance
in a global variable, rather than by constructing the player
class such that you can only instantiate a single object of that
class.

Who knows, maybe one day you’ll want to make the application
network capable, and each client can then have its own layer.

> Or are we arguing about definitions? By my thinking, any class
> which can have only one instance is, by definition,
> a singleton. Are you arguing against this ever being done, or
> against certain implementations of this?

Uh, then we’re not “arguing about definitions,” but that is
indeed where our problems are coming from. “Singleton” refers to
a very specific way of implementing classes that can only be
instantianted once, namely, a class whose constructor is private,
so that you have to retrieve an instance by using a class method,
which class method ensures that there is exactly one instance.

Not every class which is instantied only once is a singleton; the
term “singleton” specifically refers to classes which are
designed to *prevent* any API client from constructing a second
instance constructed during the runtime of the application.

If the class is not designed to prevent this, and you merely
store a single instance of it in a global variable, then that is
not a singleton.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>