What is the point of properties?

[Peter]

Hi

I was wondering, why use properties instead of get and set methods?

I have a colleague who dislikes properties - and much prefers to write
"string GetName()" and "void SetName(string name)" methods for example.

Are there any arguments as to why properties are better? Or is it just
a matter or preference? Personally I like them - I think they "look
nice", but that's about as good as I can do :-|

(And I think automatic properties are a nice enhancement too).

Thanks,
Peter

 

[Peter Macej]

There are technical differences and good reasons to use properties. I
believe someone more competent will explain them. I, as a co-author of
class documentation tool, have the following specific reasons in
addition to the other ones

Get and set methods require two XML comments and produce two entries in
generated class documentation. On the other hand, using property, there
is only one XML comment and one entry in the help, like in MSDN

There's another reason slightly related to documenting. Would you be
happy if there was no Form.Text property? How would you set the form
caption at design time? Properties can be shown and set in Properties
window. Moreover, you can add System.ComponentModel.Description
attribute to your property to display property description in Properties
window. This is not possible with methods.

 

[Chris Crowther MBCS]

There are technical differences and good reasons to use properties. I
believe someone more competent will explain them. I, as a co-author of
class documentation tool, have the following specific reasons in
addition to the other ones

Under the hood properties and get and set methods are basically the
same; the compiler actually generates two methods when it compiles the
property.

One of my friends called properties "syntactic sugar". They might well
be syntactic sugar, but they are very nice and sweet syntactic sugar.

I think one of the technical difference is when you're serializing;
properties on classes get serialized automatically, iirc.

There's another reason slightly related to documenting. Would you be
happy if there was no Form.Text property? How would you set the form
caption at design time? Properties can be shown and set in Properties
window. Moreover, you can add System.ComponentModel.Description
attribute to your property to display property description in Properties
window. This is not possible with methods.

I suspect that the Design Time integration might be one of the primary
reasons that Properties found their way in to .NET in the first place.

 

[Ignacio Machin ( .NET/ C# MVP )]

Hi

I was wondering, why use properties instead of get and set methods?

Well, the properties are actually methods , The compiler is the one
that translate them.

I have a colleague who dislikes properties - and much prefers to write
"string GetName()" and "void SetName(string name)" methods for example.

Using a property is clearer, more compact notation.

 

[ruben]

Always there are many ways to do the same thing, but look to OO concept and
theory: properties store data for an object and methods are actions an object
can be asked to perform

 

[Andy]

Hi

I was wondering, why use properties instead of get and set methods?

I have a colleague who dislikes properties - and much prefers to write
"string GetName()" and "void SetName(string name)" methods for example.

Are there any arguments as to why properties are better? Or is it just
a matter or preference? Personally I like them - I think they "look
nice", but that's about as good as I can do :-|

(And I think automatic properties are a nice enhancement too).

Thanks,
Peter

Well, yes. If you ever want to use something like Asp.Net, WinForms,
or WPF databinding, you MUST use properties. Databinding doesn't mess
around with methods.

There may be other technical reasons as well.

 

[Jeff Louie]

Just to be fair, if a well written class provides a GetName but not a
SetName,
then Name is self documenting as possibly read only.

Regards,
Jeff

 

[Arne Vajhøj]

I was wondering, why use properties instead of get and set methods?

I have a colleague who dislikes properties - and much prefers to write
"string GetName()" and "void SetName(string name)" methods for example.

Are there any arguments as to why properties are better? Or is it just
a matter or preference? Personally I like them - I think they "look
nice", but that's about as good as I can do :-|

Some classes/tools/frameworks expect properties.

It is the recommended way of doing it that future maintenance
programmers will expect to see.

So use them.

Arne

 

[Arne Vajhøj]

Using a property is clearer, more compact notation.

They are clearer because people expect them.

Unfortunately sometimes people forget that they are really
methods.

Arne

 

[Jon Skeet [C# MVP]]

On Apr 16, 9:35 pm, "Michael D. Ober"

Properties and Methods are not the same. You cannot use the databinding
features of the framework on properties - you must use methods, even if they
are nothing more than a simple get/set. This is because properties are
"executed" by the compiler and methods are "executed" by the runtime.

Um, no. Both are executed by the runtime. That's very easy to prove -
write a property whose getter retrieves information which is only
known at execution time rather than compile time, and use that
getter.

For a
property, there is a specific offset from the object (or stack frame) base
pointer to the address of the property.

It sounds very much like you're talking about fields rather than
properties.

Jon

 

[Jon Skeet [C# MVP]]

Other way around. You must use methods for databinding. I had a boatload
of classes that used properties (both C# and VB) and I had to convert all
their properties into simple get/set methods to use databinding.

Sorry, but that's just nonsense. How do you think databinding works
with the standard WinForms controls which expose pretty much
everything through properties (Text, SelectedValue etc)?

Given your other reply, it sounds like you were actually talking about
fields rather than properties - and indeed fields aren't used in
databinding, IIRC.

Jon

 

[Lasse Vågsæther Karlsen]

Under the hood properties and get and set methods are basically the
same; the compiler actually generates two methods when it compiles the
property.

One of my friends called properties "syntactic sugar". They might well
be syntactic sugar, but they are very nice and sweet syntactic sugar.

Well, "syntactic sugar" or not, syntactic sugar is what makes up quite a
bulk of C# and I for one welcome the sugar:

using (...) { ... } (translates to try/catch block)
lock (...) { ... } (translates to try/catch block)
properties (metadata + methods)
automatic properties (metadata + methods + storage)
iterator methods (state machine produced at compile time)

There is nothing wrong with syntactic sugar if it's done right.

The "with" statement of Delphi though, I'd say that is a syntactic sourball.

 

[Christopher Ireland]

The "with" statement of Delphi though, I'd say that is a syntactic
sourball.

You've probably got a better chance of getting away with that comment here
than you would do if you'd posted it to borland.public.delphi.non-technical.

;-)

--
Thank you,

Christopher Ireland
http://shunyata-kharg.doesntexist.com

"If you understand, things are just as they are; if you do not understand,
things are just as they are."
Zen Proverb

 

[Lasse Vågsæther Karlsen]

You've probably got a better chance of getting away with that comment
here than you would do if you'd posted it to
borland.public.delphi.non-technical.

;-)

I wouldn't have any problem getting away with it, the "with" statement
is usually regarded as off-limits for anyone that hasn't done lots of
Delphi programming, and they usually have the common sense to stay away
from it altogether.

For anyone not familiar with it, here's how it works:

with SomeObject do
begin
Property1 := 10;
Property2 := 'Test';
end;

this is similar to this code:

SomeObject.Property1 := 10;
SomeObject.Property2 := 'Test';

except that SomeObject, if for instance it's a method call that needs to
construct the object, is only read once in the first one.

The fun(?) comes when you write the following:

SomeValue := 10;
with SomeObject do
begin
Property1 := SomeValue;
end;

and then later someone expands SomeObject to suddenly have a new
property or field called SomeValue. Imagine the scoping fun this leads to.

Or even this:

with Object1, Object2, Object3 do
begin
Property1 := Property2;
end;

now, which objects are used here? fun for the whole family!

 

[Christopher Ireland]

Lasse,

I wouldn't have any problem getting away with it, the "with" statement
is usually regarded as off-limits for anyone that hasn't done lots of
Delphi programming, and they usually have the common sense to stay
away from it altogether.

He he he ...

Looks like it's been a few years since you visited
borland.public.delphi.non-technical. Anyhow, one thread you missed was one
entitled ""with" Coders are Monsters":

http://groups.google.com/group/borl...nt"+group:borland.public.delphi.non-technical

191 replies to that thread, so we may assume that there was some dissension
<gg>

--
Thank you,

Christopher Ireland
http://shunyata-kharg.doesntexist.com

"I am always doing that which I can not do, in order that I may learn how to
do it."
Pablo Picasso

 

[Arne Vajhøj]

On Apr 16, 9:35 pm, "Michael D. Ober"

Um, no. Both are executed by the runtime. That's very easy to prove -
write a property whose getter retrieves information which is only
known at execution time rather than compile time, and use that
getter.

An extreme but also frequently used example of a runtime oriented getter
is DateTime.Now !

It has to execute code. And there are nothing to make an offset to.

(and static versus non-static does not make a difference)

Arne

 

[Arne Vajhøj]

lock (...) { ... } (translates to try/catch block)

Hmm.

I don't think that is an accurate description of lock.

Arne

 

[Jon Skeet [C# MVP]]

On Apr 17, 8:16 pm, "Peter Duniho"

In that sense, they both "translate to try/catch block".

<pedant>
Actually, they both translate to try/finally blocks
</pedant>

Jon

 

[Ignacio Machin ( .NET/ C# MVP )]

Other way around.  You must use methods for databinding.  I had a boatload
of classes that used properties (both C# and VB) and I had to convert all
their properties into simple get/set methods to use databinding.

Mike.- Hide quoted text -

- Show quoted text -

I have always seen databinding to properties, never to methods

 

[Andy]

Other way around.  You must use methods for databinding.  I had a boatload
of classes that used properties (both C# and VB) and I had to convert all
their properties into simple get/set methods to use databinding.

No, sorry. Databinding uses reflection, and looks specifically for
properties. Part of the goal of databinding is to be able to do it in
the designer. You won't see any methods when you try to setup
databinding in the designer. Also, the databinding code itself looks
for properties.

I have no idea what you were doing, but it's not databinding as
provided with the .net framework.