Simpler syntax for properties?

[Paul E Collins]

Does anyone else think it would be nice to be able to write something like
this ...

public SomeType P { v; }

.... rather than this?

public SomeType P
{
get { return v; }
set { v = value; }
}

I realise that the property construct allows 'get' and 'set' to do more than
just assign or return a value, but in most cases - when I don't want to do
anything else - the standard form seems slightly long-winded.

P.

 

[Daniel O'Connell [C# MVP]]

Does anyone else think it would be nice to be able to write something like
this ...

public SomeType P { v; }

... rather than this?

public SomeType P
{
get { return v; }
set { v = value; }
}

I realise that the property construct allows 'get' and 'set' to do more
than
just assign or return a value, but in most cases - when I don't want to do
anything else - the standard form seems slightly long-winded.

I definatly agree, the syntax is long and not as clear as it should be. I
actually may be one of the few that thinks fields should be relegated to
sparse use and that the compiler\language should have made a greater effort
to remove the need for manual declaration of fields.

I've seen some syntax that suggests the addition of a property keyword
and\or a field associative keyword. Personally I like:
public property SomeType P{get;set;} //new keyword
or
public implicit SomeType P{get;set;} // saves a keyword, but overloads an
existing one
or just
public SomeType P{get;set;} //no keyword, but is it as clear as the above
and will people mistake it for abstract?
where the compiler generates its own field to store the backing type. P =
<value> in the declaring class calls set if its available but is transformed
into a field assign by the compiler when the property is get only. Similar
semantics could be performed for get if the property is set only. There is
some problem with that as far as how apparent the behaviour is within the
class. However I find it cleaner than trying to mix get, set, and a field
association into the property.

 

[Julie]

Does anyone else think it would be nice to be able to write something like
this ...

public SomeType P { v; }

... rather than this?

public SomeType P
{
get { return v; }
set { v = value; }
}

I realise that the property construct allows 'get' and 'set' to do more than
just assign or return a value, but in most cases - when I don't want to do
anything else - the standard form seems slightly long-winded.

What's wrong w/ just exposing the data member then?

public SomeType P;

 

[Jon Skeet [C# MVP]]

What's wrong w/ just exposing the data member then?

public SomeType P;

Everything

If you want to later change the implementation, you can't.
If you want to limit access to read or write only, you can't.
If you want to validate values on set, you can't.
If you want to trace use during debug, you can't.

Unless something is effectively constant (whether an actual const or
just something which is static, readonly and immutable), I always keep
it private.

 

[Jon Skeet [C# MVP]]

Does anyone else think it would be nice to be able to write something like
this ...

<snip>

Yes. I didn't for a while, but now I definitely do.

Unfortunately, it could get quite messy by the time you specify:

o Whether to have both a get and a set, or only one of them
o What the access levels are for each of them

One other thing about properties which I've asked for before and which
your example syntax seems to suggest is the ability to declare
variables *within* a property, but outside the accessors themselves.
They could be name-mangled slightly to avoid collisions, and would (in
the compiled IL) just be private variables - but within the C# code
itself, only the property would have access to it.

That would mean you could make absolutely sure that *all* code to
modify a particular piece of state went through the property and didn't
tamper with the variables directly.

 

[Julie]

Everything

If you want to later change the implementation, you can't.
If you want to limit access to read or write only, you can't.
If you want to validate values on set, you can't.
If you want to trace use during debug, you can't.

If I want to later change the implementation, I could simply do this:

private SomeType p; // Was: P

public SomeType P
{
get { /* ... */ }
set { /* ... */ }
}

That solves 1 and 2, right?

The OP didn't indicate the need to validate values to trace in debug. If those
are requirements, then you are right. If not requirements, then what is wrong
w/ my idea?

 

[Jon Skeet [C# MVP]]

If I want to later change the implementation, I could simply do this:

private SomeType p; // Was: P

public SomeType P
{
get { /* ... */ }
set { /* ... */ }
}

That solves 1 and 2, right?

No - you've just broken your public interface, so anything using it
needs to be recompiled. Using properties, the public interface stays
the same even if the implementation changes.

The OP didn't indicate the need to validate values to trace in debug. If those
are requirements, then you are right. If not requirements, then what is wrong
w/ my idea?

The above. If the OP's requirements for tracing, validation etc change
(as they often do), using properties provides a backward-compatible way
of working. Fields don't.

 

[Guest]

----- Jon Skeet [C# MVP] wrote: ----

One other thing about properties which I've asked for before and which

your example syntax seems to suggest is the ability to declare
variables *within* a property, but outside the accessors themselves.
They could be name-mangled slightly to avoid collisions, and would (in
the compiled IL) just be private variables - but within the C# code
itself, only the property would have access to it

or even better, alleviate the need to manually declare a private field altogether. introduce a new keyword, they already have *value* right? have something like *state* for example. so you can do something like get { return state; } set { state = value }, and let the compiler handle the declaration of the underlying field in IL. then that will solve the whether to prefix fields with "_" or "m_" debate once and for all. added bonus

 

[Daniel O'Connell [C# MVP]]

No - you've just broken your public interface, so anything using it
needs to be recompiled. Using properties, the public interface stays
the same even if the implementation changes.

Not to mention that its possible code would break if the field is used as a
ref or out parameter, as has been coming up in these groups alot lately.
Its considerably less likely, but it is an issue, IMHO.

 

[Jon Skeet [C# MVP]]

or even better, alleviate the need to manually declare a private
field altogether. introduce a new keyword, they already have *value*
right? have something like *state* for example. so you can do
something like get { return state; } set { state = value }, and let
the compiler handle the declaration of the underlying field in IL.
then that will solve the whether to prefix fields with "_" or "m_"
debate once and for all. added bonus.

Hmm... not sure about that, except in the very simple case where you
can declare the whole property in one statement.

Not every property will have a single backing variable, and I wouldn't
want a variable to be automatically generated some times but not
others.

 

[Guest]

you are right, this only works in very simple cases where it's 1-1 mapping with matching type as well

----- Jon Skeet [C# MVP] wrote: ----

or even better, alleviate the need to manually declare a privat
field altogether. introduce a new keyword, they already have *value
right? have something like *state* for example. so you can d
something like get { return state; } set { state = value }, and le
the compiler handle the declaration of the underlying field in IL
then that will solve the whether to prefix fields with "_" or "m_
debate once and for all. added bonus

Hmm... not sure about that, except in the very simple case where you
can declare the whole property in one statement

Not every property will have a single backing variable, and I wouldn't
want a variable to be automatically generated some times but not
others

 

[John Vottero]

Everything

I don't know enough of the details to say that I disagree but, I don't think
you've really answered the question.

If you want to later change the implementation, you can't.

Sure you can, or are you saying that you can't change the implementation
without forcing consumers to rebuild?

If you want to limit access to read or write only, you can't.
If you want to validate values on set, you can't.

But, the question started with the simple case of get/set and no validation.
If you just want a simple get/set unvalidated property, what's wrong with
exposing the field?

If you want to trace use during debug, you can't.

Now that's a good point!

 

[Jon Skeet [C# MVP]]

I don't know enough of the details to say that I disagree but, I don't think
you've really answered the question.


Sure you can, or are you saying that you can't change the implementation
without forcing consumers to rebuild?

The latter - I must admit I'd taken backwards compatibility as an
assumption. I don't like changing public interfaces.

Of course, customers may well have also written code which uses
reflection which assumes that the member is a field, in which case
their code could break in subtle ways even after a rebuild.

But, the question started with the simple case of get/set and no validation.
If you just want a simple get/set unvalidated property, what's wrong with
exposing the field?

If you don't mind breaking backwards compatibility, not a lot. I just
find it a better habit never to expose any public mutable fields in the
first place. (MS agrees, incidentally: http://tinyurl.com/26qey)

Now that's a good point!

It's the least important one for me, usually, but everyone has
different views