What I don’t like is that we have properties and also the readonly thing. Somehow I’d more like a unification of concepts.

Come to think of it, in Eiffel, you can’t do this

a . b = c

unless

a = this

On the other hand, readonly is stricter yet, as it doesn’t even allow methods in the same class to alter it - except constructors.

So if the new get-only pattern will generate a readonly variable, then that’d probably be a good thing, as it would automatically make the code more strict, I think.

I think Anders H. himself dislikes the “many ways to Rome” - meaning the syntax should be as canonical as possible without making it oversimplistic.

But you can question that with some of the syntax in C#.

Some syntax can seem arbitrary. But I suppose that’s a characteristic of any ad-hoc language.

I vastly prefer C#’s properties to Java’s reflection getX, setX, though. Even if it is a more canonical syntax (less is more). But less is more is only usable to a certain extent as not all of us enjoy brainfuck or assembler.

I like both the attribute idea and adding the “property” keyword idea. I think the attribute idea is more flexible in that hopefully the Property attribute could be extended so that we could create our own property implementations (e.g. adding INotifyPropertyChanged). However, I think the “property” keyword would be more consistent with the way C# works now (when comparing it to the “event” keyword).

In any case, I think the original proposed idea is awful. It seems that Ayende Rahien (no offense) is the only commenter to support it so far, so I hope it doesn’t stick.

When I try to give definition to what is going on with the proposed way of adding automatic properties, I come up with “If the Member is not implemented and it does not have an abstract keyword then have the compiler do the work.”

Here is that definition applied to an existing two different scenarios:

1) public abstract string MyProperty { get; set; }
This property is not implemented. Fine. It has an abstract keyword, so that’s cool.
2) public string MyProperty { get; set; }
This property is not implented. Fine. Wait a minute… no abstract keyword. I’ll create the property for you!

So now apply this to a method.
1) public abstract void MyMethod();
This method is not implemented. Fine. It has an abstract keyword, so that’s cool.
2) public void MyMethod();
This method is not implemented. Fine. Wait a minute… no abstract keyword. I’ll create the method for you! Wait… umm…. how do I do that? … should I do that? What’s going on? INCONSISTENCIES!!! NOOOOO!!!! OMG!!! BOOOOM!

Now on the other hand consider these two lines:
public event MyEvent;
public property string MyProperty;

Both have similar syntaxes. Both have automatically-generated code. It’s a perfect succession.

It only makes sense (to my VB.Net loving mind) that this be allowed to be explicitly defined as
public property string MyProperty { get{} set {} }

See the similarities(!!!!????):
public property string MyProperty;
public property string MyProperty { get{} set {} }

public event MyProperty;
public event MyProperty { add{} remove {} }

Ahh… my brain relaxes at the overwhelming consistency of the above four lines. As Andrew said above, I’m completely against “continual cognitive dissonance”!

….
After writing all this, I decided my point would become clearer if I blogged some very concrete syntax examples. They can be found here:
http://joshmouch.wordpress.com/2007/02/16/syntax-consistency-among-class-members-events-properties-and-methods/

I know what you mean. I used to pride myself on my pointer arithmetic. But on reflection, that’s madness. I drive a car with an automatic gearbox because I’m confidant that it can change gears better than I can. The same ought to be true for the mindless drudgery of keeping track of objects. The nicest language ought to be the most transparent - the one where you have to think least of all about what the likely syntax fora given construct ought to be. When the language designers start adding non-intuitive syntaxes to save on typing, something’s wrong.

As Ayende pointed out, there is a disambiguation in C# for non-implemented abstract properties - the abstract keyword. Although that is not necessary for interfaces (I have to admit I still think of interfaces as pure abstract classes, even though they’re not in C#). I can’t help feeling that if this trend of gilding the lily continues the language will be a mass of special cases, with a different thought process for each construct. the end result will be a continual cognitive dissonance, which will put people off it altogether.

I admit I’m being a little alarmist, but I still think that clarity ought to triumph over brevity!

As for unsigned types, I presume you mean that if you use System.Uint32 you are violating CLS compliance? I also wonder why they never included that as a requirement for the CLS… Of course if that is not an issue, then you can use it with impunity :-)

public property string MyProperty;
-or-
public readonly property string MyProperty;

because it is much more similar to how events are declared by default. And you could control serialization in the same way:

[field: NonSerialized]
public property string MyProperty;

I guess the difference comes about when you explicitly implement the property because you drop the “property” keyword, whereas you don’t drop the “event” keyword when you explicitly implement an event:

public string MyProperty
{
get { … }
set { … }
}

Kent

The only things missing were the generics and unsigned types on the framework. We no have the first but unfortunately we are not going to have the second one because of some other languages. Why the hell do we have to use int for the age of a person? I wish I didn’t have to validate it…

Anyway, I think these last changes, like nameless delegates, will only confuse people. C# will end up like C++, too confusing…

Antao

Whether this warrants more syntactic sugar is debatable, and I certainly don’t like the proposed way of doing things. I’d much prefer:

public property string MyString { get; set; }

If you need to customize the backing field then write it. This is analogous to how events work:

public event EventHandler MyEvent; //uses the default backing store

public event EventHandler MyEvent
{ //use whatever backing store you want
add {}
remove {}
}

My 2c,
Kent