Something I'd like to see in C#

[Andrew Ducker]

Static methods are fantastic. Static classes even moreso. You can
call them from anywhere in a very simple manner, making them useful
"Helper" classes. But they lack one very useful trick - they can't be
subclassed. If you want a range of helper classes with similar
functionality then you either have to put that shared code into a
different static class that they all access or use a singleton
pattern instead.

(And while I don't know how often the singleton pattern is used
elsewhere, it's certainly one that I bump into on a very regular
basis. For those that don't about it, it's a class that only allows a
single copy of itself to be instantiated. For more about them, and
guidelines on writing your own see http://www.yoda.arachsys.com/csharp/singleton.html
where Jon Skeet gives some useful examples.)

In any case, it's something that's common, too easy to implement badly
in multithreaded applications, and the resulting code isn't as pretty
as it could be. What I'd like is a new keyword in the language that
solves all of these - "singleton".

If a class is declared "singleton" then it should be possible to
access its methods directly, in the same way that a method is on a
static class. In effect, MySingleton.Instance.MyMethod() would be
replaced by MySingleton.MyMethod() - and the compiler would deal with
creating your singleton in a safe and efficient way.

Code before:
public class SingletonClass
{
private SingletonClass(){ }
public static readonly SingletonClass Instance = new
SingletonClass();
public void MyMethod()
{
....
}
}
and to call it:
SingletonClass.Instance.MyMethod();

Code after:
public singleton class SingletonClass
{
public void MyMethod();
}
and to call it:
SingletonClass.MyMethod();

And yes, I know the chances of me actually getting a change made to C#
is slim to none, but this has been bugging me for a few days, and I
thought I'd throw it out there to see what other people thought.

Cheers,

Andy

 

[Jon Harrop]

And yes, I know the chances of me actually getting a change made to C#
is slim to none, but this has been bugging me for a few days, and I
thought I'd throw it out there to see what other people thought.

F# is the evolution of C# and already provides everything you're asking for
and a whole lot more.

 

[Jon Skeet [C# MVP]]

And yes, I know the chances of me actually getting a change made to C#
is slim to none, but this has been bugging me for a few days, and I
thought I'd throw it out there to see what other people thought.

I think that embedding a design pattern which is overused directly into
the language is a bad idea.

Singletons have their uses, but they're used too often IMO. I wouldn't
like to see that overuse increased by direct language support.

 

[Ignacio Machin \( .NET/ C# MVP \)]

HI,

In any case, it's something that's common, too easy to implement badly
in multithreaded applications, and the resulting code isn't as pretty
as it could be. What I'd like is a new keyword in the language that
solves all of these - "singleton".

If a class is declared "singleton" then it should be possible to
access its methods directly, in the same way that a method is on a
static class. In effect, MySingleton.Instance.MyMethod() would be
replaced by MySingleton.MyMethod() - and the compiler would deal with
creating your singleton in a safe and efficient way.

As you mentioned the code for generating such a class is simple, the
language should be kept as simple as possible and this is not such a feature
I would like to see in the language itself.

A betteer solution would be to have a snippet that makes the class singleton

 

[Alun Harford]

Static methods are fantastic. Static classes even moreso. You can
call them from anywhere in a very simple manner, making them useful
"Helper" classes. But they lack one very useful trick - they can't be
subclassed. If you want a range of helper classes with similar
functionality then you either have to put that shared code into a
different static class that they all access or use a singleton
pattern instead.

(And while I don't know how often the singleton pattern is used
elsewhere, it's certainly one that I bump into on a very regular
basis. For those that don't about it, it's a class that only allows a
single copy of itself to be instantiated. For more about them, and
guidelines on writing your own see http://www.yoda.arachsys.com/csharp/singleton.html
where Jon Skeet gives some useful examples.)

In any case, it's something that's common, too easy to implement badly
in multithreaded applications, and the resulting code isn't as pretty
as it could be. What I'd like is a new keyword in the language that
solves all of these - "singleton".

I've used a singleton in one situation in C#. When programming for
managed Direct3D, you should only ever instantiate a single Device, so
the core of my graphics engines tends to use a singleton to wrap the Device.

As a general rule, if you're frequently using singletons, you either
need to think more about your design, or you're writing device drivers.

Alun Harford

 

[sp3d2orbit]

Static methods are fantastic. Static classes even moreso. You can
call them from anywhere in a very simple manner, making them useful
"Helper" classes. But they lack one very useful trick - they can't be
subclassed. If you want a range of helper classes with similar
functionality then you either have to put that shared code into a
different static class that they all access or use a singleton
pattern instead.

(And while I don't know how often the singleton pattern is used
elsewhere, it's certainly one that I bump into on a very regular
basis. For those that don't about it, it's a class that only allows a
single copy of itself to be instantiated. For more about them, and
guidelines on writing your own seehttp://www.yoda.arachsys.com/csharp/singleton.html
where Jon Skeet gives some useful examples.)

In any case, it's something that's common, too easy to implement badly
in multithreaded applications, and the resulting code isn't as pretty
as it could be. What I'd like is a new keyword in the language that
solves all of these - "singleton".

If a class is declared "singleton" then it should be possible to
access its methods directly, in the same way that a method is on a
static class. In effect, MySingleton.Instance.MyMethod() would be
replaced by MySingleton.MyMethod() - and the compiler would deal with
creating your singleton in a safe and efficient way.

Code before:
public class SingletonClass
{
private SingletonClass(){ }
public static readonly SingletonClass Instance = new
SingletonClass();
public void MyMethod()
{
....
}}

and to call it:
SingletonClass.Instance.MyMethod();

Code after:
public singleton class SingletonClass
{
public void MyMethod();}

and to call it:
SingletonClass.MyMethod();

And yes, I know the chances of me actually getting a change made to C#
is slim to none, but this has been bugging me for a few days, and I
thought I'd throw it out there to see what other people thought.

Cheers,

Andy

If static inheritance were added to the language then there wouldn't
be a reason to the singleton keyword. A static class is pretty much a
singleton class, it even has constructors, just no inheritance.

 

[Andrew Ducker]

If static inheritance were added to the language then there wouldn't
be a reason to the singleton keyword. A static class is pretty much a
singleton class, it even has constructors, just no inheritance.

Static inheritance would do it nicely, yes.

Andy

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Static methods are fantastic. Static classes even moreso. You can
call them from anywhere in a very simple manner, making them useful
"Helper" classes. But they lack one very useful trick - they can't be
subclassed. If you want a range of helper classes with similar
functionality then you either have to put that shared code into a
different static class that they all access or use a singleton
pattern instead.

Classes with static methods can be subclassed.

Are you asking for polymorphism of static methods ?

If a class is declared "singleton" then it should be possible to
access its methods directly, in the same way that a method is on a
static class. In effect, MySingleton.Instance.MyMethod() would be
replaced by MySingleton.MyMethod() - and the compiler would deal with
creating your singleton in a safe and efficient way.

Code before:
public class SingletonClass
{
private SingletonClass(){ }
public static readonly SingletonClass Instance = new
SingletonClass();
public void MyMethod()
{
....
}
}
and to call it:
SingletonClass.Instance.MyMethod();

Code after:
public singleton class SingletonClass
{
public void MyMethod();
}
and to call it:
SingletonClass.MyMethod();

I like singleton pattern and have used it frequently, but I still don't
think it belongs in the language.

And if your singleton class constructor has arguments then
the line savings in your version decreases a lot.

Arne

PS: I usualy use a property and not a field for Instance.