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?

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

> 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

>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

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.

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

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.

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

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

# object foo {
#    // just like a class
# };


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

-- Matthias Becker

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.