www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Singleton as a feature of the language

reply nail <nail_member pathlink.com> writes:
Hi all.

Why not to make singleton classes a feature of D to avoid ugly constructions ala

class MyClass : Singleton!(MyClass)
{
}

or

class MyClass
{
mixin ThisClassIsSingleton!(MyClass)
}

void main()
{
MyClass.instance.blablabla();
}

or something else. First it would be safer (no typeid must be transmited to
template) and second it would be much readable:

singleton class MyClass
{
int a = 0; // notice: no static label
}

void main()
{
MyClass.a = 5;
MyClass c = new MyClass;
c.a = 6; // MyClass.a became 6
}

This is very like make all in class 'static' with only big difference. Memory
like in most singleton patterns must be allocated at first requst to a class and
deallocated at application termination.

If you predict usage before first request and want ctor to be run you can just
write "new MyClass". Also if you want to release it before application exits you
can write "delete MyClass" and if there no instanciated objects of this class it
must be destroyed and dtor take place. If you try to access already released
singleton it's behaviour must be the same if it never was created (i.e. new mem
must be allocated, ctor runed etc) like in phoenix patern.

Something against?
Dec 25 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
nail wrote:

 Hi all.
 
 Why not to make singleton classes a feature of D to avoid ugly constructions
ala
 
 [...]
 
 Something against?


Things to consider for addition into a language should generally be 
ideas which simply can't be expressed any other way, or without strange, 
ugly contortions.  Second, it really needs to be orthogonal to existing 
constructs, lest ambiguities take over the language.

Coroutines, for instance, simply cannot be implemented any other way, 
and tend to be extremely good at expressing state machines in a 
straightforward manner.

Singletons, on the other hand, are useful in relatively few situations 
(some go so far as to declare them evil), and can be expressed within 
the existing language by adding a single line of code to a class.

Alternatively, singletons can be effected by simply declaring all data 
and functions at module scope instead of using a class.

  -- andy
Dec 25 2004
next sibling parent Andrey Taranov <ataranov lobnya.com> writes:
 Alternatively, singletons can be effected by simply declaring all data 
 and functions at module scope instead of using a class.


Yes, I totally agree. Singletons were born in languages with no clear 
module concept. Even where the concept of a class and of a module are 
confused, like Java.

In a good language, there should be both modules *and* classes, as we 
happily have in D. These notions should not be reduced to only one of them.

And the Singleton pattern is implemented really good as a plain module 
of code. If you absolutely must have a singleton as an object, then you 
may declare a public interface and a private class implementing the 
interface in this module, plus a public module function like 
getInstance(). Voila, a cleanly implemented Singleton.

Regards,
Andrey
Dec 26 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Alternatively, singletons can be effected by simply declaring all data 
and functions at module scope instead of using a class.


But singletons can inherit from other classes, singletons have constructors,
singletons can be lazyly created, ...

Seems like you confuse "singleton" with "mono state"?

-- Matthias Becker
Dec 27 2004
next sibling parent nail <nail_member pathlink.com> writes:
In article <cqoq0j$1317$1 digitaldaemon.com>, Matthias Becker says...

Alternatively, singletons can be effected by simply declaring all data 
and functions at module scope instead of using a class.


But singletons can inherit from other classes, singletons have constructors,
singletons can be lazyly created, ...

Seems like you confuse "singleton" with "mono state"?


Yes, yes. What about inheritance, polymorphism, etc, etc.
Dec 27 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Matthias Becker wrote:

Alternatively, singletons can be effected by simply declaring all data 
and functions at module scope instead of using a class.


 
 But singletons can inherit from other classes, singletons have constructors,
 singletons can be lazyly created, ...


In these cases, you're stuck with 'mixin Singleton!(MyClass);', which 
doesn't strike me as being a big deal.  It's not terribly hard to 
understand or remember, and I'm unaware of any subtle problems that it 
might introduce later.


 Seems like you confuse "singleton" with "mono state"?


... pay no attention to the man behind the curtain!

  -- andy
Dec 27 2004
parent Matthias Becker <Matthias_member pathlink.com> writes:
Alternatively, singletons can be effected by simply declaring all data 
and functions at module scope instead of using a class.


 
 But singletons can inherit from other classes, singletons have constructors,
 singletons can be lazyly created, ...


In these cases, you're stuck with 'mixin Singleton!(MyClass);', which 
doesn't strike me as being a big deal.  It's not terribly hard to 
understand or remember, and I'm unaware of any subtle problems that it 
might introduce later.


Right. And I'd never vote for a singleton as part of the language.
Dec 29 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
nail wrote:

 Hi all.
 
 Why not to make singleton classes a feature of D to avoid ugly constructions
ala


<snip>

I'm not sure about the singleton's usefulness in D.  The way the Java 
API uses them seems to be a way around Java's requirement that 
everything be in a class.  True, C++ programmers sometimes use 
singletons as well, apparently as a way of grouping functions/variables 
together.

In this respect, singletons are much the same as modules.  The obvious 
difference is syntactical - at the moment, we have:

Option       Member access
Module       yuiop
Static       Qwert.yuiop
Singleton    Qwert.getInstance().yuiop

The module notation is the shortest, but it doesn't make it clear what 
component yuiop is part of.  Of course, this could be overcome by naming 
the module members to include the component name....

The static members option provides, I guess, a 'best of both worlds' 
syntax, but does it have many other virtues?  Likewise, it's used quite 
a bit in the Java API.  Again, this is a makeshift for the 'everything 
in a class' requirement, and using classes for what they aren't really for.

This leaves the singleton.  Some of you have mentioned lazy construction 
as an advantage of this approach.  But this is only really of value if 
it uses up a significant amount of memory or needs run-time 
initialisation.  But D classes and modules can have static constructors, 
and I think Java classes can as well.  And if you're not going to use it 
in a given program, you can just not import/link in the module.

This leaves the issue of singletons within a library.  I'm not sure how 
static constructors work at the moment, but I'm guessing it's down to 
the import tree rooted at the module that implements main (or WinMain or 
whatever).  If so, it means that a static constructor won't be called if 
the module is never imported while compiling the 'main' module.  But 
what if some library module Asdfg has a feature depending on Qwert, but 
Asdfg is otherwise usable without this feature?  Either Qwert would need 
to be a singleton with lazy initialisation, or memory/time would be 
wasted initialising a module that is never used.  But is this a 
compelling case?

For that matter, are there any languages out there that have singletons 
as an actual feature?  How do they work?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.
Dec 28 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 Why not to make singleton classes a feature of D to avoid ugly constructions
ala


<snip>

I'm not sure about the singleton's usefulness in D.  The way the Java 
API uses them seems to be a way around Java's requirement that 
everything be in a class.


Nope.
Look e.g at the math lib. 

Java uses classes as namespaces/module, it doesn't use singletons as
namespaces/module.


True, C++ programmers sometimes use 
singletons as well, apparently as a way of grouping functions/variables 
together.


Nope. They use either namespaces or they use structs with static member
functions.

In a singletont normaly there is only one static member function with is called
instance, getInstance, create, or something similar.



In this respect, singletons are much the same as modules.  


No! If you use singletons as modules you haven't got the idea of singletons. A
singleton is a class that can be instanciated only once. Use a singleton
whenever it is an error to have multiple instances of a class.



The obvious 
difference is syntactical - at the moment, we have:

Option       Member access
Module       yuiop
Static       Qwert.yuiop
Singleton    Qwert.getInstance().yuiop


A module is "instanciated" independent of whether you use it or bot, sigletons
are instanciated lazily, so you can't compare the anyway.



The module notation is the shortest, but it doesn't make it clear what 
component yuiop is part of.


You can write Qwert.yuiop if you want to!


Of course, this could be overcome by naming 
the module members to include the component name....


That would be stupid. A module or namespace system prevents us from being fored
to use these crappy prefixes.


The static members option provides, I guess, a 'best of both worlds' 
syntax, but does it have many other virtues? Likewise, it's used quite 
a bit in the Java API.


Static members aren't syntacitcaly different from module members. You don't have
to qualify, but you can. A static member of a class forces you to qualify.
That's the only difference.


Again, this is a makeshift for the 'everything 
in a class' requirement, and using classes for what they aren't really for.


Right, as said you have modules or namespaces for this.


This leaves the singleton. Some of you have mentioned lazy construction 
as an advantage of this approach. But this is only really of value if 
it uses up a significant amount of memory or needs run-time 
initialisation. But D classes and modules can have static constructors, 
and I think Java classes can as well. And if you're not going to use it 
in a given program, you can just not import/link in the module.


What about inheritance? You could implement the nil-object pettern as a
singleton, but you can't do this by a module.



For that matter, are there any languages out there that have singletons 
as an actual feature? How do they work?


Scala:






Anyway I think it's a stupid idea to make a singleton build in in D, as the
mixin approach is perfect.

-- Matthias Becker
Dec 30 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Matthias Becker wrote:

 Why not to make singleton classes a feature of D to avoid ugly 
 constructions ala


 
 <snip>
 
 I'm not sure about the singleton's usefulness in D. The way the 
 Java API uses them seems to be a way around Java's requirement that 
 everything be in a class.


 
 Nope.
 Look e.g at the math lib. 


Neither java.lang.Math nor java.math look to me like evidence that the 
Java API doesn't use singletons.


 Java uses classes as namespaces/module, it doesn't use singletons as 
 namespaces/module.


Uh huh ... java.lang.Runtime


 True, C++ programmers sometimes use singletons as well, apparently 
 as  a way of grouping functions/variables together.


 
 Nope. They use either namespaces or they use structs with static member 
 functions.


You mean you've spoken to every C++ programmer on the planet, and none 
of them use singletons?  Even the one you're talking to, who's used them 
in one or two projects?


 In a singletont normaly there is only one static member function with 
 is called instance, getInstance, create, or something similar.


Mine had them just as global objects.  Of course there wasn't anything 
to stop someone from creating another object of the type, but there 
didn't need to be as they were specific to the application.  Of course, 
whether that means it's not really a singleton, I'm not sure.


 In this respect, singletons are much the same as modules.


 
 No! If you use singletons as modules you haven't got the idea of 
 singletons. A singleton is a class that can be instanciated only 
 once. Use a singleton whenever it is an error to have multiple 
 instances of a class.


You only have one instance of a module.
You only have one instance of a singleton.

So how is this a difference?


 The obvious difference is syntactical - at the moment, we have:

 Option       Member access
 Module       yuiop
 Static       Qwert.yuiop
 Singleton    Qwert.getInstance().yuiop


 
 A module is "instanciated" independent of whether you use it or bot, 
 sigletons are instanciated lazily, so you can't compare the anyway.


Oh, it seems you're using a stricter definition of "singleton" than I
was. I'd never thought of lazy instantiation as part of the definition.

<snip>

 What about inheritance? You could implement the nil-object pettern as 
 a singleton, but you can't do this by a module.


Since I'm not sure what a nil-object is, and I haven't really time to 
look into it now, I can't comment at the moment.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
on the 'group where everyone may benefit.
Dec 31 2004