Suggestions for .Net CLR

[Phoenix]

A couple of suggestions for enhancing the .Net CLR:

Property indexers:
To be able to have an indexed property (as opposed to a
type's indexer) without having to create a subtype.

Example:
class MyClass
{
public int MyIndexedProperty[int index]
{
get{...}
set{...}
}
}
....
MyClass o = new MyClass();
o.MyIndexedProperty = foo;

This would reduce coding by reducing the number of
auxiliary types that need to be defined to do the same
thing today.

---------------------------------------------------------
Static indexers:
Useful when a type has a list of possible instances,
rather than a named set.

Example:
public struct MyStruct
{
static MyStruct[] myStructs;
public static this[int index]
{
get{return mystructs[index];}
}
}
....
MyStruct o = MyStruct

The same can be accomplished thru a typical static
property, but this notation seems a bit cleaner.

------------------------------------------------------
Different accessibility on property gets and sets:
A favorite technique of mine in my VB6 days; still
lamenting its loss in the CLR. VB6 allowed us to have a
property that had
a public get accessor, and a friend set accessor, like so:

Public Property Get MyProperty As Long
Friend Property Let MyProperty(lValue As Long)

This used to be great; the project's internal code could
use the same property name to set a property that the
public interface exposed for gets. Now, we have to define
2 properties with 2 different names to get the same effect:

public int MyProperty
{
get{return myProperty;}
}
internal int MyProperty_Internal
{
set{myProperty = value;}
}

Example of what I'd really like to code for this:
public int MyProperty
{
get {return myProperty;}
internal set {myProperty = value;}
}

Even if it were just a compiler trick, this ability would
be awesome to have back.

 

[Jon Skeet]

A couple of suggestions for enhancing the .Net CLR:

Property indexers:
To be able to have an indexed property (as opposed to a
type's indexer) without having to create a subtype.

<snip>

This already exists in the CLR - it's just that C# doesn't expose it
I agree though - it would be handy.

<snip>

Hmmm... possibly. Can't say I'm quite as keen on this one. Put it this
way: it's not a need I've run into.

<snip>

This is coming in Whidbey, I believe. (And about time too.)

What I'd like (and I've mentioned this before on the C# newsgroup) is
to be able to declare a variable as local to a property - it could then
only be accessed by that property. It would remain as a private
class/instance variable in the actual class definition, but nothing
other than the property and any constructors/methods which had a
specific attribute (to make things like serialization simpler) would be
able to access the variable. It wouldn't need anything in the CLR apart
from the new attribute, which the CLR wouldn't need to actually know
about anyway - it would all be done in the compiler.

 

[Phoenix]

-----Original Message-----


<snip>

Hmmm... possibly. Can't say I'm quite as keen on this one. Put it this
way: it's not a need I've run into.

This would be good, for example, if the list of named
colors in .Net were dynamic:

Color.Add("ToxicGreen", Color.FromARGB(0, 104, 128, 68));
....
myForm.BackColor = Color["ToxicGreen"];

or for holding a collection of single-instance objects.
CodeTables.Add("States", statesTable);
....
cboState.DataSource = CodeTables["States"];

This lets one define a true "static collection". But
again, this would pretty much be just a convenient
shorthand for current static collection DP's.

What I'd like (and I've mentioned this before on the C# newsgroup) is
to be able to declare a variable as local to a property - it could then
only be accessed by that property.
<snip>

Ah, method static variables. I miss these too, they'd be
great for busting event loops and the like. I'm not sure
why these weren't ported from C/C++. Conventional wisdom
has always held that you declare a variable at the lowest
possible scope, and that scope and lifetime are linked but
different concepts. And this wouldn't even affect the CLR
one iota; the compiler could treat it as a type-level
member, and simply enforce the scope during compile.
(Pretty much re-hashing what you said.)

Phoenix

 

[Jon Skeet]

Ah, method static variables. I miss these too, they'd be
great for busting event loops and the like.

No, I wasn't suggesting method static variables at all. I was just
suggesting that for properties only, you could declare:

string Whatever
{
string whatever;

get { return whatever; }
}

(or whatever)

and nothing else could get at x and y.

I'm not sure
why these weren't ported from C/C++. Conventional wisdom
has always held that you declare a variable at the lowest
possible scope, and that scope and lifetime are linked but
different concepts. And this wouldn't even affect the CLR
one iota; the compiler could treat it as a type-level
member, and simply enforce the scope during compile.
(Pretty much re-hashing what you said.)

The reason is that usually if you want to store extra state, that state
should be to do with the *object*, not the *method*. I personally don't
miss them - except for the single case of properties, which is just a
way of hiding the implementation of a property away from the rest of
the class.

 

[Jon Skeet]

string Whatever
{
string whatever;

get { return whatever; }
}

(or whatever)

and nothing else could get at x and y.

<snip>

That should, of course, say that nothing else could get at the
"whatever" variable.