Why doesn't ToString require ()

  • Thread starter Thread starter tshad
  • Start date Start date
That is why I asked you to tell me the logic, in other words,  why do we
need on the caller side to know what work is done on the sender side.

AFAIK is one of the principles of Oop that nobody should care how something
is returned, only that it is returned.
Click to expand...

You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).

In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.

(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
But isn't the '"usually", "imo", "generally", etc' exactly the point? There
is no logical distinction between a property and a method. Should a call
that has previously been a method now become a property because the
developer has found a way to safely persist the value and has done away with
the query back to the data base? I certainly want to know that the
performance has been improved in this way, but why should this hidden
internal detail cause me to now think about the item in a completely
different way? And if I'm not thinking about it quite differently, why do
we have the two separate concepts?

rowe_newsgroups said:
That is why I asked you to tell me the logic, in other words, why do we
need on the caller side to know what work is done on the sender side.

AFAIK is one of the principles of Oop that nobody should care how
something
is returned, only that it is returned.
Click to expand...

You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).

In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.

(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Göran Andersson said:
Well, that's only half the truth, and hardly even that...

It's not C# that overrides (not overloads) the operators
Click to expand...

It overloads the operators (overloading in the sense of language, not
programming)! The meaning of the '==' operator is ambiguous. You can't
answer the question if the '==' operator in the 'a == b' expression compares
the values or the references without knowing the types of the variables 'a'
and 'b' respectively. That's IMO a huge design problem leading to
confusion, because it requires exact knowledge about the types involved even
when attempting to perform a type-agnostic reference comparison.
C# consistently uses the comparisons defined in the framework
Click to expand...

That's true, but it exposes these comparisons in an inconsistent way, making
the use of 'ReferenceEquals' even necessary for reference types overriding
'Equals'. C# does not have distinct operators for value and reference
comparison. It only has a dubious '==' operator which changes its meaning
depending on the types and makes the use of 'ReferenceEquals' necessary in
cases where it performs value comparison although reference comparison is
desired. Even JavaScript' does not have such an awkward comparison operator
design.
 
To me the biggest difference is the syntax when the property or method
is used.

If I use a property I can say:
val = obj.Prop
obj.Prop = val

If I use a method I need two methods, something like:
val = obj.GetProp()
obj.SetProp(val)

For things that have a single value, the property syntax makes more
sense to me, and the code in the class is cleaner - the Set and Get
code is together.

For something more complicated, either because the Set has no values,
multiple values or the Set needs to return a status then I would use
the method syntax. The processing time isn't that important to me in
deciding which to use. If you are using a property or method it is
your responsibility to know the ramifications of that use (can it
block for a long time, what are the side effects, etc.). To me a
property is appropriate when you are setting a single value that you
will want to examine later, or a readonly property for a value that
you only want to look at.

And don't forget that something like a property is needed for
databinding, unless you want to specify two methods for the binding,
one to set and one to get.

There will always be gray areas, no matter what your criteria is for
deciding between the two.
 
To me I like knowing whether a property or a method is being
called. Strictly speaking you can do the same functionality in either,
but many / most coding guidelines recommend not having much, if any,
functionality inside properties. When reading code that clearly calls
a property (i.e. no parentheses) I don't need to be on my guard for
unexpected behind-the-scenes behaviors as I do with methods.
Click to expand...

I personally find the opposite is true, particularly in terms of assuming
how much behind-the-scenes work is going on. Because VB doesn't really
differentiate in terms of parenthesising, I just view every property set/get
call as a sub/function respectively and try not to make assumptions as to
what's going on behind the scenes. If it's my own code I'll generally know
anyway, and if it's not then I won't be trusting of it regardless, lol.

In terms of languages, it's the usual "each to his own" choice. I prefer
VB's easy going nature and it's explicit notations for ending blocks, but I
can see why many prefer the stricter punctuation rules of C# and the
"elegance" of the curly braces.
 
Seth

You cannot change the method ToString in a property in an existing
situation.

Cor

rowe_newsgroups said:
That is why I asked you to tell me the logic, in other words, why do we
need on the caller side to know what work is done on the sender side.

AFAIK is one of the principles of Oop that nobody should care how
something
is returned, only that it is returned.
Click to expand...

You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).

In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.

(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Göran Andersson said:
Ok, I'll try to explain the difference.

A property of an object is just what it sounds like. It's a value that
you can read and write. Reading or writing a property should generally
not cause any significant work to be done.
Click to expand...

The whole point of having a property versus having a field is that the
property at least potentially encapsulates logic.


If the property is "number of legs" then it should be quick and not
require much work if it's "current net value" then it might require
quite a lot of work.
A method is where you put code that does some work. You send some values
to the method, it does something, and you get the result back.

To use a method as if it was a property hides the fact that some
significant work might be done.
Click to expand...

Except when profiling, you shouldn't be giving a lot of thought to how
much work a piece of code does.
I don't understand what you mean by that. What is it that you are
comparing that to?
Click to expand...

He's calling it religious/tradition, not logic.
 
Cor said:
Goran,

The way you describe a property is in my idea a little bit useless way.
By instance as I set the property of the backcolour of a textbox, then it is
something more then only setting a value, I know that most persons mostly
use it (including I) only as you wrote.
Click to expand...

The background colour of a text box is clearly a property. You can set
the value, and you can get the value. It doesn't make sense to implement
it as anything else.
However, why do I need to know on the invoking side what it is a property or
a method, the work that is done in the invoked class does absolute not
interest me.
Click to expand...

In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.

http://en.wikipedia.org/wiki/Object-oriented_programming
In my idea go people in a black suit to the church, no one know why, but it
is always done like that.
Click to expand...

Well, you can either accept object oriented programming and "wear the
black suit", or you can reject it. In that case you should probably
choose a different language that isn't object oriented...
 
Göran Andersson said:
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.

http://en.wikipedia.org/wiki/Object-oriented_programming
Click to expand...

Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.

And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.

For instance, the total net worth of a person, may not be a simple
matter of adding the checking and saving accounts together and then
subtracting outstanding debts, so you might have a parent class called
People and then sub-classes RichPeople and PoorPeople where the
property CurrentNetValue is calculated differently.
 
So if an object can be instructed to change a characteristic of itself (such
as a user control instructed to change its background color) should that
instruction be implemented as a property or as a method?

If we really maintained the distinction you refer to we would need two steps
in the process - a change of the property value and an invocation of a
method to force the object to do whatever the change in the property
requires. That doesn't happen, and there is no reason that it should. So
what purpose is served by the distinction between changing the value of a
property and performing some action in response to that change?

From the other viewpoint, in many cases when the object does something we
want to know the result of that action. If we maintained the distinction
that you refer to we would need two steps in the process - a method to
instruct the object to carry out the action, and then retrieve the property
that indicates the result.

In practice, the distinction you refer to does not exist, and the
classification of an process as property or method seems to be pretty much
arbitrary.

For example, why are we still saying
myVar += 1
when the OOP terminology is surely
mvVar.Math.Add(1)
 
J.B. Moreno said:
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
Click to expand...

Of course you should.

There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
Click to expand...

If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.

The debugger in Visual Studio, for example, relies heavily on this
difference between properties and methods. When displaying an object it
reads all the properties to get their values, but it doesn't call all
the methods to get their return values.
 
James said:
So if an object can be instructed to change a characteristic of itself
(such as a user control instructed to change its background color)
should that instruction be implemented as a property or as a method?
Click to expand...

If it's a characteristic of the object that you can access, it should
usually be a property.
If we really maintained the distinction you refer to we would need two
steps in the process - a change of the property value and an invocation
of a method to force the object to do whatever the change in the
property requires. That doesn't happen, and there is no reason that it
should. So what purpose is served by the distinction between changing
the value of a property and performing some action in response to that
change?

From the other viewpoint, in many cases when the object does something
we want to know the result of that action. If we maintained the
distinction that you refer to we would need two steps in the process - a
method to instruct the object to carry out the action, and then retrieve
the property that indicates the result.
Click to expand...

That is logical if the result of the operation determines a
characteristic of the object. Then you would already have the property,
and it would only be natural that the method changed the state of the
object.

For example, you can call the Open method of the SqlConnection class.
The open method doesn't have a return value, but if it succeded the
State property will change.
In practice, the distinction you refer to does not exist, and the
classification of an process as property or method seems to be pretty
much arbitrary.
Click to expand...

It does exist, and I showed you an example of how it's used in the
framework.
For example, why are we still saying
myVar += 1
when the OOP terminology is surely
mvVar.Math.Add(1)
Click to expand...

That is just syntactic sugar for using the addition operator. What it
actually does is reading the value, adding one to it and assigning the
result to the variable:

myVar = myVar + 1;

The addition operator actually works as a static method (and can be
overloaded like one for your own classes), so what it actually does is:

myVar = Int32.operator+(myVar, 1);

This is of course optimised by the JIT compiler into the ADD
instruction, so it will not be a method call when adding the built-in types.
 
Göran Andersson said:
Of course you should.

There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
Click to expand...

That depends upon what you are doing (for instance you might be
modeling a Heisenberg object where the position or velocity can be
known, but not both).

But in general I consider it good programming practice to (a) document
side effects, (b) minimize side-effects. You can't rely upon the
property/method distinction to determine whether or not there were
side-effects (a pet object might have an owners property that hit the
database for instance with all that implies).

This isn't about OOP, it's about what you consider best practice, for
your own code, not something you can even begin to rely upon as best
practice for someone else's code.
If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.
Click to expand...

Caching should be used whenever it makes sense, and not used when it
doesn't (for instance DateTime values all have a Now Property, caching
that wouldn't make any sense).
 
James Hahn said:
So if an object can be instructed to change a characteristic of itself (such
as a user control instructed to change its background color) should that
instruction be implemented as a property or as a method?
Click to expand...

As a property.

The distinction between the a method and a property is a useful
conceptional tool -- see bundle theory of objecthood.

Methods are abilities, properties are characteristics -- while you can
have some overlap, that's because we are writing code not dealing with
fundamental truths of the universe.
If we really maintained the distinction you refer to we would need two steps
in the process - a change of the property value and an invocation of a
method to force the object to do whatever the change in the property
requires. That doesn't happen, and there is no reason that it should. So
what purpose is served by the distinction between changing the value of a
property and performing some action in response to that change?
Click to expand...

No. If an object has a property, then changing the property changes
the expression (after a bit of time delay because computers can't do
everything at once) of that property. If you have a class Dogs and
amputate a particular dog's leg, then when displaying that dog, it
should have the correct number of legs.

Or to put it in database terms, changing a property is a transaction,
that either succeeds or fails -- if you set the background color of an
object to blue and the background continues to display in yellow, then
your object is broken.

This is not to say the distinction isn't useful, it is. With an
object, we want to know what it *is* as well as what it can *do*. We
will make use of this when classifying it and interfacing with it.
 
J.B. Moreno said:
That depends upon what you are doing (for instance you might be
modeling a Heisenberg object where the position or velocity can be
known, but not both).

But in general I consider it good programming practice to (a) document
side effects, (b) minimize side-effects. You can't rely upon the
property/method distinction to determine whether or not there were
side-effects (a pet object might have an owners property that hit the
database for instance with all that implies).

This isn't about OOP, it's about what you consider best practice, for
your own code, not something you can even begin to rely upon as best
practice for someone else's code.
Click to expand...

This is general OOP guidelines. If I inherit code from someone else, and
I find a class where reading properties changes the state of the object,
I would definitely consider that as a bug.
Caching should be used whenever it makes sense, and not used when it
doesn't (for instance DateTime values all have a Now Property, caching
that wouldn't make any sense).
Click to expand...

The Now property is static, so it's not an example of an object property.

If getting the value of a property is a lengthy process, it should
always be cached if possible. If it takes a few seconds to get the
value, you can cache it for another few seconds. If you want to perform
the lengthy process every time, it should be a method rather than a
property.
 
J.B. Moreno said:
J.B. Moreno wrote:





This is general OOP guidelines. If I inherit code from someone else, and
I find a class where reading properties changes the state of the object,
I would definitely consider that as a bug.


The Now property is static, so it's not an example of an object property.

If getting the value of a property is a lengthy process, it should
always be cached if possible. If it takes a few seconds to get the
value, you can cache it for another few seconds. If you want to perform
the lengthy process every time, it should be a method rather than a
property.
Click to expand...

In addition, from a testing standpoint, having properties that
encapsulate a great deal of logic can be a shear nightmare. Especially
if you try to use many of the various mocking platforms, where it is
nigh impossible to set expectations and monitor behaviors when the
logic lives inside properties. My personal favorite, Rhino.Mocks,
(afaik) treats properties as simple get, set blocks and will blow up
trying to set an expectation on them. You can set expectations on
readonly properties, but even then there tends to be some "gotchas"
you wouldn't get with functions.

Most of the times that I see developers adding functionality to
properties, it's on a project with zero unit tests and is done out of
laziness. There is a development stigma against functions; functions
are "expected" to be complex routines that are fully tested, and most
bugs are blamed on poor implementation of the logic inside a function.
To me it seems that many people think that putting the logic into a
property, particularly readonly properties, makes their code safer and
less likely to break. In other words it's a security blanket of
sorts.

If it were up to me, all properties would be defined as C#
autoimplemented properties (public string MyProperty { get; set; }) so
that you couldn't add any additional functionality. Sure there are
cases where you need more functionality, such as firing XChanging
XChanged events or caching, but those could be done with attributes,
etc. I firmly believe that any logic that needs to be tested (yes
everything should be tested, but simple properties normally don't have
a good ROI from testing) should live in a method.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
Click to expand...
Click to expand...
 
Göran Andersson said:
If it's a characteristic of the object that you can access, it should
usually be a property.
Click to expand...
But my point was that your definition does not provide a basis for deciding
this. Surely changing its appearance is 'something an object can do'. Why
have you chosen the 'characteristic' side of the definition instead of the
'change' side? For a more dramatic example, consider the view property of a
ListView - a change in one enumerated property casuses major changes to the
display and functionality of the control.

I am not arguing that these things shouldn't be properties, but simply
wondering whether there is a more rigorous basis for making the distinction
between properties and methods that can effectively guide the programmer
(which I think was the origianl question in the thread). It must be a
problem for workgroups having this decision decided at the team level
without adequate guidance for the programmer to make the decision
themselves. In my own case, I know that I am frequently inconsistent. For
instance,

myRobot.Speed += 3
but
myRobot.Direction(Left, 10)

simply because of the way I expected to be passing the arguments. I can
easily imagine someone else thinking exactly the opposite.

I suspect the real distinction has nothing to do with characteristics and
actions, but rather is in the compiler and IDE technical detail - issues
with initialization, overloading, shadowing, context, optimization,
protection and so on. Or, that there is no real distinction and the
programmer is free to use whatever is most convenient in the circumstances.
 
Back
Top