C# properties: nothing more syntactic sugar for getters and setters

N

Neil Zanella

Hello,

It seems to me that C# properties are nothing more than syntactic sugar for
getters and setters. I wonder whether others hold a different point of view.
Basically, what more do they have to offer?

Thank you for your replies,

Best Regards,

Neil
 
J

Jon Skeet [C# MVP]

Neil Zanella said:
It seems to me that C# properties are nothing more than syntactic sugar for
getters and setters. I wonder whether others hold a different point of view.
Basically, what more do they have to offer?

Nothing - just as the using statement (and directive, come to that)
offers nothing more than syntactic sugar. Of course, all of these give
incredibly *useful* syntactic sugar...

Actually, there *is* a difference between having a property and just
having a getter and a setter - the CLR knows it's a property too, so
it's exposed in reflection as a property.
 
Z

Zach

Neil Zanella said:
Hello,

It seems to me that C# properties are nothing more than syntactic sugar for
getters and setters. I wonder whether others hold a different point of view.
Basically, what more do they have to offer?

Thank you for your replies,

Best Regards,

Neil

What bullshit.
 
H

Helge Jensen

Syntactic suger runs many languages: "for(s1; e; s2) s3;" is syntactic
sugar for "s1; while(e) { s3; s2; }", but very usefull.

The "using(T t = e) { s1;...;sN; }" is (almost, since it can also uses
Close()) syntactic sugar for "T t = t; try { s1;...;sN; } finally {
t.Dispose(); }"

They provide a way to declare "fields" in interfaces, (like .Count)

They provide a way to just declare a public field right now, you can
always add some code to verify the updates of the field later without
changing the syntax of the code using the field.

Also, the type-system on them is a bit different than on get/set, since
a property is "one" entity and get/set are two functions with separate
types.

This is importent when declaring interfaces:

interface Foo { int i { get; } }

Declares an interface where NO implementation of Foo can have a "set"
part for i. While this is not really a usefull restriction declare, it
is a rather annoying restriction to have applied to ones classes :)

A (slightly confusing maybe) workaround for the restriction is:

class Bar: Foo
{
int Foo.i { get { return i; } }
public int i { get { ... } set { ...} }
}

Which lets people set i with "bar.i = 5" if they know bar as an instance
of Bar, but not if they know it as Foo.
 
J

Jon Skeet [C# MVP]

Also, the type-system on them is a bit different than on get/set, since
a property is "one" entity and get/set are two functions with separate
types.

This is importent when declaring interfaces:

interface Foo { int i { get; } }

Declares an interface where NO implementation of Foo can have a "set"
part for i.

I don't think this is true. For instance:

using System;
using System.IO;
using System.Text;

interface IProperty
{
int IntProperty
{
get;
}
}

class Test : IProperty
{
int intProperty;

public int IntProperty
{
get { return intProperty; }
set { intProperty = value; }
}

static void Main()
{
Test t = new Test();
t.IntProperty = 10;
Console.WriteLine (t.IntProperty);
}
}
 
G

Guest

Actually, there *is* a difference between having a property and just
having a getter and a setter - the CLR knows it's a property too, so
it's exposed in reflection as a property.

I think this is an important distinction that we don't emphasize enough
during our weekly visits to this issue.

My understanding from reading the langauge history, is that properties and
events are in the language mostly to support component-oriented programming.
They are also convenient, so that's a nice added bonus. I prefer them to
writing BeanInfo classes like they do in the Java world.

I would also argue that they make the programmers intent more obvious and
the code is therefore more self-describing.
 
H

Helge Jensen

Jon said:
I don't think this is true. For instance:

You are quite right. As this (rather smaller) test shows in my compiler:

interface Foo { int i { get; } }
class Bar: Foo { public int i { get { return 0; } set { int _i =
value; } } }

But I'm pretty sure I had this problem once, and that FxCop also
reported it to me.

Anyone got anything to add here, did it use to be a problem at some
point in the past?
 
B

Bob Grommes

Properties are syntactically much more natural to use and more
self-documenting than get/set methods. The data in a user defined type
should act like data and be addressed like data, rather than like a
behavior.

--Bob
 
P

Peter N Roth

Properties [can] keep all the code that deals
with a specific field "in close proximity" so
when a change is made to 'get', the appropriate
change can be made to 'set' without having to
do much of a search of the rest of the code body.

--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET
 
J

James Curran

Neil Zanella said:
It seems to me that C# properties are nothing more than syntactic sugar for
getters and setters. I wonder whether others hold a different point of view.
Basically, what more do they have to offer?

They offer syntactic sugar. Why isn't that good enough?

One could argue that all programming language are just syntactic sugar
over assembly language (which is itself syntactic sugar over machine code).

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
J

John Wood

Exactly.
Another reason is that you can quite easily determine whether a property is
readonly by getting the PropertyInfo and checking the CanWrite property --
it would be far more difficult to do that if you were using 'get' and 'set'
methods.

In fact, assuming they're comparing to Java, there isn't even any reflection
in Java so you couldn't do it at all.

--
John Wood
Blog: http://spaces.msn.com/members/johnwood/


James Curran said:
Neil Zanella said:
It seems to me that C# properties are nothing more than syntactic sugar for
getters and setters. I wonder whether others hold a different point of view.
Basically, what more do they have to offer?

They offer syntactic sugar. Why isn't that good enough?

One could argue that all programming language are just syntactic sugar
over assembly language (which is itself syntactic sugar over machine code).

--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
 
R

Richard Blewett [DevelopMentor]

Sorry, but there is reflection in Java. Look at the java.lang.reflect namespace

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Exactly.
Another reason is that you can quite easily determine whether a property is
readonly by getting the PropertyInfo and checking the CanWrite property --
it would be far more difficult to do that if you were using 'get' and 'set'
methods.

In fact, assuming they're comparing to Java, there isn't even any reflection
in Java so you couldn't do it at all.
 
J

John Wood

oops, i haven't used java for over 6 years and i didn't recall it being in
there back then but i may have missed it... sorry!
 
J

Jon Skeet [C# MVP]

John Wood said:
oops, i haven't used java for over 6 years and i didn't recall it being in
there back then but i may have missed it... sorry!

It's been present since Java 1.1, which shipped in Feb 97.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top