C# language wish list

[JS]

There are 2 features that I keep wishing C# had. These are not
groundbreaking ideas, and I haven't given these too much thought, but
I wonder if others have also wanted these types of language features.

1. C# Keywords for reflection. The idea here is that we can access
PropertyInfo through a keyword. An example might be: PropertyInfo
pinfo = propertyInfo(MyClass.TestProperty);
Where "propertyInfo" is the new keyword. My motivation for this is
that now I can change the name of "TestProperty" to something else and
VS refactoring will be able to find this reference to the property.
This could extend to other reflection types like MethodInfo as well.

2. Namespaces inside classes. Some classes can get quite large and it
would be useful to break down methods and properties into categories.
Look at all the methods, properties, and events inside any WinForms
control for instance and there are just too many. Here's an example
of a class using my proposed namespace idea:

class Panel
{
namespace Appearance
{
public Color BackgroundColor { get; set; }
}
}

Then you'd use an instance of Panel like this:
panel.Appearance.BackgroundColor = Color.Blue;
I guess class namespaces could be labeled as sealed, public, private,
protected as well, although I haven't thought about this too much. In
addition to just being able to categorize methods, properties and
events, there are some repercussions which come from this. For
example, you could now have 2 methods in a class with the same
arguments but different return types, as long as they are in different
namespaces.

 

[Anthony Jones]

There are 2 features that I keep wishing C# had. These are not
groundbreaking ideas, and I haven't given these too much thought, but
I wonder if others have also wanted these types of language features.

1. C# Keywords for reflection. The idea here is that we can access
PropertyInfo through a keyword. An example might be: PropertyInfo
pinfo = propertyInfo(MyClass.TestProperty);
Where "propertyInfo" is the new keyword. My motivation for this is
that now I can change the name of "TestProperty" to something else and
VS refactoring will be able to find this reference to the property.
This could extend to other reflection types like MethodInfo as well.

Thats somewhat esoteric. Reflection is a useful feature of .NET but it I
wouldn't have thought it to be a common day to day thing that many C#ers
would be doing. I wouldn't want the language cluttered with keywords that
have marginal use.

2. Namespaces inside classes. Some classes can get quite large and it
would be useful to break down methods and properties into categories.
Look at all the methods, properties, and events inside any WinForms
control for instance and there are just too many. Here's an example
of a class using my proposed namespace idea:

class Panel
{
namespace Appearance
{
public Color BackgroundColor { get; set; }
}
}

Then you'd use an instance of Panel like this:
panel.Appearance.BackgroundColor = Color.Blue;
I guess class namespaces could be labeled as sealed, public, private,
protected as well, although I haven't thought about this too much. In
addition to just being able to categorize methods, properties and
events, there are some repercussions which come from this. For
example, you could now have 2 methods in a class with the same
arguments but different return types, as long as they are in different
namespaces.

Such a syntax would save two extra lines:-

class Panel
{
private AppearanceType myAppearance = new AppearanceType();

internal AppearanceType Appearance { get { return myAppearance; } }

internal class AppearanceType
{
public Color BackGroundColor{ get; set; }
}
}

Again its a little out there. If I found I had so many proprties that I
needed this sort of solution I would be questioning my design. Perhaps
Appearance may be worth promoting to a sibling class rather than a nested
one.

 

[JS]

The reflection keyword idea is to deal with things like data binding,
which is used by lots of C# developers.

I know the class namespace idea can already be donebut I find myself
using that internal class quite a bit. I also find that my internal
class often needs a reference to the class that owns it.

 

[Marc Gravell]

The first is discussed regularly - a "nameof" or "infoof" operator. I
agree with the usefulness in particular of the simple "nameof", but we
shall have to see if anything ever materialises. However, note that
with .NET 3.5 you can create a method to do this using Expression and
lambda

http://groups.google.co.uk/group/mi...read/thread/f44dc57a9dc5168d/4805324df6b30218
http://groups.google.co.uk/group/mi...read/thread/e7b0f0539f85745e/ddf914f92ef43047

I'll let you decide if it is worth it or not...

Marc

 

[Arne Vajhøj]

There are 2 features that I keep wishing C# had. These are not
groundbreaking ideas, and I haven't given these too much thought, but
I wonder if others have also wanted these types of language features.

1. C# Keywords for reflection. The idea here is that we can access
PropertyInfo through a keyword. An example might be: PropertyInfo
pinfo = propertyInfo(MyClass.TestProperty);
Where "propertyInfo" is the new keyword. My motivation for this is
that now I can change the name of "TestProperty" to something else and
VS refactoring will be able to find this reference to the property.
This could extend to other reflection types like MethodInfo as well.

I think the use of reflection and reference to field by itself and
not by name is a contradiction.

2. Namespaces inside classes. Some classes can get quite large and it
would be useful to break down methods and properties into categories.
Look at all the methods, properties, and events inside any WinForms
control for instance and there are just too many.

Namespaces is a well defined concept in other languages - you
can not change the meaning of that term.

Besides I think VS region is providing some of the functionality
you want.

Arne

 

[Alun Harford]

There are 2 features that I keep wishing C# had. These are not
groundbreaking ideas, and I haven't given these too much thought, but
I wonder if others have also wanted these types of language features.

The first request is pretty normal.
The second suggests poor seperation of concerns.

It's rare that a class should be over 100 lines of code (unless it's not
actually a class but a big horrible blob of nasty code).

Alun Harford