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]]

"Paul E Collins" <fi******************@CL4.org> wrote in message
news:c5**********@sparta.btinternet.com...

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]

Paul E Collins wrote:

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]]

Julie <ju***@nospam.com> wrote:

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Paul E Collins <fi******************@CL4.org> wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Julie]

"Jon Skeet [C# MVP]" wrote:

Julie <ju***@nospam.com> wrote:

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.

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]]

Julie <ju***@nospam.com> wrote:

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?

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Daniel Jin]

----- 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

--
Jon Skeet - <sk***@pobox.com
http://www.pobox.com/~skee
If replying to the group, please do not mail me to

[Daniel O'Connell [C# MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Julie <ju***@nospam.com> wrote:

> 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?

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Daniel Jin <an*******@discussions.microsoft.com> wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too