Property or Function?

[sklett]

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and "How do
you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes into a
property and what should be a function?

[Brian Gideon]

Bruce Wood wrote:

In this particular example I would chose a function over a property.
The reason is because a lot (most?) people assume that properties are
constant time operations.

I don't know about "constant time operations," but it's true that
properties shouldn't take much time to execute. That said, I have many,
many properties in the framework I built at my company that could, in
theory, go back to the database for information, so they're waaaay over
"constant time."

You see, it's not always so cut-and-dried.

Oh yeah. I completely agree. Another example of where I would bend
the rule is lazy initialization or singletons.

[sklett]

wow, good times! ;0)

I think I will leave it. I read everyones various takes on things, some I
agree with more than others. As far as times goes, this is a FAST process
so I'm not concerned with that. Keeping an additional member with the
precalculated duration isn't appealing as I would need to add a type and an
"Add()" method to my class, I would also need to have a "Remove()" method.

Nice to see everyones opinions though, also nice to see that there isn't a
cut and dry answer.
Enjoy your Sundays!

-SK

"sklett" <sk****@mddirec t.com> wrote in message
news:OL******** *****@TK2MSFTNG P05.phx.gbl...

I just found myself doing something I haven't before:
<code>
public uint Duration
{
get
{
uint duration = 0;
foreach(Thing t in m_things)
{
duration += t.Duration;
}

return duration;
}
}
</code>

And it made me think... "Is that OK to do stuff" in a property?" and "How
do you decide to use a property or a function?"

So, that's my question: Are there guidelines for deciding what goes into
a property and what should be a function?

[Nick Hounsome]

"Brian Gideon" <br*********@ya hoo.com> wrote in message
news:11******** **************@ v46g2000cwv.goo glegroups.com.. .

Bruce Wood wrote:

> In this particular example I would chose a function over a property.
> The reason is because a lot (most?) people assume that properties are
> constant time operations.

I don't know about "constant time operations," but it's true that
properties shouldn't take much time to execute. That said, I have many,
many properties in the framework I built at my company that could, in
theory, go back to the database for information, so they're waaaay over
"constant time."

You see, it's not always so cut-and-dried.

Oh yeah. I completely agree. Another example of where I would bend
the rule is lazy initialization or singletons.

There are particular problems with lazy initialization and accessing remote
data:-

I think that one thing that most people would agree about properties is that
they don't expect them to throw exceptions.

IMHO this rules out accessing any remote data source in a property since
there are just too many ways that it can fail that are not the fault of the
application.

This can be a problem for any property but it is particularly unexpected
with singletons and lazy initialization.

[Brian Gideon]

Nick Hounsome wrote:

There are particular problems with lazy initialization and accessing remote
data:-

I think that one thing that most people would agree about properties is that
they don't expect them to throw exceptions.

IMHO this rules out accessing any remote data source in a property since
there are just too many ways that it can fail that are not the fault of the
application.

This can be a problem for any property but it is particularly unexpected
with singletons and lazy initialization.

Yes. On second thought singletons might not be a good situation to
bend the rules. Some of the same guidelines that are considered when
authoring a property apply to constructors as well. I usually avoid
long operations in constructors as does most of the .NET Framework BCL.
If you adhere to that rule then a property exposing a singleton would
be fast anyway.

[Bill Butler]

"Nick Hounsome" <nh***@nickhoun some.me.uk> wrote in message
news:Ze******** ***********@fe2 .news.blueyonde r.co.uk...

I think that one thing that most people would agree about properties is that they don't expect
them to throw exceptions.

I am not sure that I agree with that.
In general the reason that most properties don't throw exceptions is that they do very little that
*could* cause an Exception. Getters are often little more than a way of making data read only. But,
just because they often don't throw exceptions, it doesn't follow that they *shouldn't* throw
Exceptions.

Almost any non-trivial settable properties will need *some* validation.

The Hashtable.Item Property throws
ArgumentNullExc eption and
NotSupportedExc eption
the ArrayList.Capac ity Property throws
ArgumentOutOfRa ngeException
Even some getters throw Exceptions
the FileInfo.Length Property throws
IOException and
FileNotFoundExc eption

the DirectoryInfo.P arent Property throws
SecurityExcepti on
Sometimes Exceptions do make sense for properties

Granted, sometimes the presence of exceptions being thrown in a property could be a signal that the
class should be rewritten.

Just my 2 cents
Bill

[Brian Gideon]

The no exception from properties rule generally only applies to
getters. The rule does not apply to indexers. Thats per the Framework
Design Guidelines book.

Bill Butler wrote:

"Nick Hounsome" <nh***@nickhoun some.me.uk> wrote in message
news:Ze******** ***********@fe2 .news.blueyonde r.co.uk...

I think that one thing that most people would agree about properties is that they don't expect
them to throw exceptions.

I am not sure that I agree with that.
In general the reason that most properties don't throw exceptions is that they do very little that
*could* cause an Exception. Getters are often little more than a way of making data read only. But,
just because they often don't throw exceptions, it doesn't follow that they *shouldn't* throw
Exceptions.

Almost any non-trivial settable properties will need *some* validation.

The Hashtable.Item Property throws
ArgumentNullExc eption and
NotSupportedExc eption
the ArrayList.Capac ity Property throws
ArgumentOutOfRa ngeException
Even some getters throw Exceptions
the FileInfo.Length Property throws
IOException and
FileNotFoundExc eption

the DirectoryInfo.P arent Property throws
SecurityExcepti on
Sometimes Exceptions do make sense for properties

Granted, sometimes the presence of exceptions being thrown in a property could be a signal that the
class should be rewritten.

Just my 2 cents
Bill

[Nick Hounsome]

"Bill Butler" <qw****@asdf.co m> wrote in message
news:KcC_f.8128 $rm3.3969@trndn y06...

"Nick Hounsome" <nh***@nickhoun some.me.uk> wrote in message
news:Ze******** ***********@fe2 .news.blueyonde r.co.uk...

I think that one thing that most people would agree about properties is
that they don't expect them to throw exceptions.
I am not sure that I agree with that.
In general the reason that most properties don't throw exceptions is that
they do very little that *could* cause an Exception. Getters are often
little more than a way of making data read only. But, just because they
often don't throw exceptions, it doesn't follow that they *shouldn't*
throw Exceptions.

Almost any non-trivial settable properties will need *some* validation.

This is a totaly different situation as the exception is caused by the
caller doing something wrong rather than the class failing its contract.

Considering only getters - it goes back to the logical meaning of a
property - it is something that you have and therefore you cannot logically
fail to return it as seems reasonable with GetX().

The Hashtable.Item Property throws
ArgumentNullExc eption and
NotSupportedExc eption
the ArrayList.Capac ity Property throws
ArgumentOutOfRa ngeException
Even some getters throw Exceptions
the FileInfo.Length Property throws
IOException and
FileNotFoundExc eption
I would say that this should not be a property and the problem is caused by
the incorrect naming. The class does not encapsulate File information it
merely provides a way to get the latest information about a file over which
it has no control.

IMHO the class should snapshot all the info and use properties (in which
case there can be no exceptions from the properties)

If you were to name the class from its behaviour it would have to be called
FileInfoAccesso r or something similar and use methods.

the DirectoryInfo.P arent Property throws
SecurityExcepti on

I think that this is acceptable as it is a failure on the part of the caller
in much the same way as for a setter range exception.

To clarify: I don't think that it is acceptable for an object to say "this
is a 'property' of myself - an essential aspect of my existence and yet I
can't seem to actually find it at the moment. Sorry!"

[Bill Butler]

>"Nick Hounsome" <nh***@nickhoun some.me.uk> wrote in message

news:61******* **************@ fe3.news.blueyo nder.co.uk...

"Bill Butler" <qw****@asdf.co m> wrote in message news:KcC_f.8128 $rm3.3969@trndn y06...

<snip>

Almost any non-trivial settable properties will need *some* validation.

This is a totaly different situation as the exception is caused by the caller doing something
wrong rather than the class failing its contract.

OK, I can agree with that.
Considering only getters - it goes back to the logical meaning of a property - it is something
that you have and therefore you cannot logically fail to return it as seems reasonable with
GetX().
As a general guideline, I agree.
Once real life and optimization rear their head, sometimes we need to bend the rules.
Suppose you have a file that consists of a bunch of fixed length records.
Each line(or group of lines) translates into an object(or heirarchy of objects).
For the sake of arguement, let's say each line is information about a person.
Ideally, you would read in the data and validate/parse it either in a helper class or in the
constructor of the person object. By the time the object is created it has everything it needs to
produce non-exception throwing properties. After all, if something were invalid we would catch it at
instantiation time.

So Far I agree with your assessment.

Now, suppose that we find that our program performs like a pig.
Here we are validating/parsing EVERY field when all we wanted to know was who was from New Jersey.
So we get the bright idea of lazy evaluation. We will only extract the properties from the text
string when it is needed.
I program perform much better BUT, now validation occurs when the property is executed and not at
instantiation time. Arguably, I could change
if (person.State == "NJ")
into
if(person.Parse State() == "NJ") // or GetState or whatever

But I would argue that the first form is much cleaner.
I could also have a Person class that had non throwing properties as well as a LazyPerson class that
implemented the same IPeson interface but could throw exceptions.

This particular sort of case has come up time and again in the work that I have done.
So, while I agree that most types of object should have non throwing properties, sometimes real life
intrudes and we need to bend the rules.
<snip>

Even some getters throw Exceptions
the FileInfo.Length Property throws
IOException and
FileNotFoundExc eption

I would say that this should not be a property and the problem is caused by the incorrect naming.
The class does not encapsulate File information it merely provides a way to get the latest
information about a file over which it has no control.

I can understand your point, but I'm OK with it the way it is too.
IMHO the class should snapshot all the info and use properties (in which case there can be no
exceptions from the properties)

If you were to name the class from its behaviour it would have to be called FileInfoAccesso r or
something similar and use methods.

the DirectoryInfo.P arent Property throws
SecurityExcepti on
I think that this is acceptable as it is a failure on the part of the caller in much the same way
as for a setter range exception.

OK, agreed
To clarify: I don't think that it is acceptable for an object to say "this is a 'property' of
myself - an essential aspect of my existence and yet I can't seem to actually find it at the
moment. Sorry!"

<grin>
Uhhhh, what was my cell phone number again???/
Damn, I never call myself.
Nick, I really don't disagree with you.
Complex exception throwing thigamajigs tend to belong in methods.
Properties in general should be quick, and locally accessible.

But I feel that it is a guideline as opposed to a rule.
You should definitely stop and think twice about your design if your getters are throwing
exceptions.
But, if the situation warrants it,....Go ahead.

Bill