How to handle a property?

[Papa.Coen]

Contrary to what the title might make you believe; this is not a n00b
question.

I recently came across a problem with using a property which made me
question the way I use/see properties in general. The problem was with
changing item values in a DataRow. The dotNET DataRow class has a
ItemValues property which returns an object array containing item
values.
I tried to change some of these values by passing this object array to
a method using the property as a parameter:

this.DoSomething(row.ItemArray);

But allas, ItemArray does not actually return the internal item value
list but a copy in the shape of an object array. I thought (and still
do) this was strange, I only use properties for controlled access to
my private member variables and avoid putting logic in get/set blocks
and when using a property I expected to access a private member
variable as well. What is even worse is that I had to use Reflector to
find out what ItemArray actually does, since it's not documented in
MSDN (for as far as I can find). This leads to tedious trial-and-error
(although I've managed with my view of Properties so far ;)

If the behaviour of ItemArray is something that might be expected then
using the following code is very dangerous:

this.DoSomething(myObject.HisProperty.HerProperty. TheirProperty);

Especially when a property value is(/might be) changed allong the way.
To be absolutely safe this should be rewritten to something like;

object a = myObject.HisProperty;
object b = a.HerProperty;
object c = b.TheirProperty;
this.DoSomething(c);
b.TheirProperty = c
a.HerProperty = b
myObject.HisProperty = a

Here:
http://msdn.microsoft.com/library/de...guidelines.asp
MS states that a method should be used if an array is returned.

See here for code examples:
http://www.navelpluis.nl/index.php?o...id=21&Itemid=5

So what defines a propertie and what can be expected from it?

[Patrick Steele]

In article <11**********************@p10g2000cwp.googlegroups .com>,
pa*******@gmail.com says...

I recently came across a problem with using a property which made me
question the way I use/see properties in general. The problem was with
changing item values in a DataRow. The dotNET DataRow class has a
ItemValues property which returns an object array containing item
values.
I tried to change some of these values by passing this object array to
a method using the property as a parameter:

this.DoSomething(row.ItemArray);

According to the documentation on ItemArray:

"Gets or sets all the values for this row **through an array**"

The emphasis is mine. It sounds like to me you can either "get" all the
values into an array, or you can "set" all of the values from an array.
I don't see any individual "set a single item" semantics in this. For
that you'd need to use the Item property.

And my next question is why not just past the DataRow since that is what
you want updated. By passing just the array, you're asking DoSomething
to update the array -- not the DataRow.

My 2 cents... :)

--
Patrick Steele
http://weblogs.asp.net/psteele

[Papa.Coen]

According to the documentation on ItemArray:

>
"Gets or sets all the values for this row **through an array**"

The emphasis is mine. It sounds like to me you can either "get" all the
values into an array, or you can "set" all of the values from an array.

So 'through an array' means that it is generated, not a member var?

I don't see any individual "set a single item" semantics in this. For
that you'd need to use the Item property.

Documentation doesn't even(or always) state that when this ìs actually
possible. Like when a properties does return a member array. But I
don't want to make this thread a discussion about documentation and/or
formulation but about the definition of a property.

And my next question is why not just past the DataRow since that is what
you want updated. By passing just the array, you're asking DoSomething
to update the array -- not the DataRow.

This is not the point. If the misinterpretation happens here, I can
happen anywhere.
Next to that, it was my intention to only update its values and using
a property for a parameter in a method call isn't something strange or
something you should avoid. The classes I mention are only used to
illustrate my 'problem'.

[Patrick Steele]

In article <11**********************@a34g2000cwb.googlegroups .com>,
pa*******@gmail.com says...

According to the documentation on ItemArray:

"Gets or sets all the values for this row **through an array**"

The emphasis is mine. It sounds like to me you can either "get" all the
values into an array, or you can "set" all of the values from an array.

So 'through an array' means that it is generated, not a member var?

That's the way I'm interpreting it. And it sounds like from your
experience, that's the way it is working.

And my next question is why not just past the DataRow since that is what
you want updated. By passing just the array, you're asking DoSomething
to update the array -- not the DataRow.

This is not the point. If the misinterpretation happens here, I can
happen anywhere.

I was just curious as to why you were taking that approach. It doesn't
seem "natural" to me. But that's just me.

Next to that, it was my intention to only update its values and using
a property for a parameter in a method call isn't something strange or
something you should avoid. The classes I mention are only used to
illustrate my 'problem'.

I didn't mean to imply it was strange. It's not strange for a property
that exposes a reference type. It's definitely something to avoid with
a value type since you're only getting a copy.

--
Patrick Steele
http://weblogs.asp.net/psteele

[Quoc Linh]

On Feb 2, 6:39 am, "Papa.Coen" <[e-mail]:

But allas, ItemArray does not actually return the internal item value
list but a copy in the shape of an object array.

So what defines a propertie and what can be expected from it?

This is a good approach to return array from a class, by return a
shallow copy instead of a reference, and control update the content of
the array/collection variable via a specific method.

QL

[Papa.Coen]

This is a good approach to return array from a class, by return a

shallow copy instead of a reference, and control update the content of
the array/collection variable via a specific method.

I understand it's safer but using an array property will result in a
lot of overhead, since changing a single array element requires you to
copy an entire array twice! Does this concern all collection types
then or is it just the DataRow class and then again : how could I have
known? I still believe the documentation is not very clear on this
point. I want to figure out what can be expected of a property.

[Patrick Steele]

In article <11*********************@j27g2000cwj.googlegroups. com>,
pa*******@gmail.com says...

I want to figure out what can be expected of a property.

I think that is a documentation issue.

And I agree that "ItemArray" really shouldn't be a property -- they
should have a GetItemValues() and SetItemValues() methods. As you
pointed out earlier (either in this thread or via email), Microsoft's
documentation states that properties shouldn't return arrays. It's too
ambiguous as to what you're being given.

Even Microsoft makes mistakes in their designs. ;)

--
Patrick Steele
http://weblogs.asp.net/psteele

[Papa.Coen]

So let's conclude that using properties requires a bit more attention
than might be expected :)
Thank you for your insights.

If anyone else has something to say, I'm still curious to what other
people think about this subject...

[Barry Kelly]

Papa.Coen wrote:

This is a good approach to return array from a class, by return a
shallow copy instead of a reference, and control update the content of
the array/collection variable via a specific method.

I understand it's safer but using an array property will result in a
lot of overhead, since changing a single array element requires you to
copy an entire array twice!

This is the reason that properties which return arrays are not
recommended. For example, FxCop will complain about it, and the
Framework Design Guidelines advise against it.

Does this concern all collection types
then or is it just the DataRow class

The collection types use indexed properties, not properties of an array
type. These two things are different. If you consider a property P of
type T as a combination of 'T get_P()' and (optional) 'void set_P(T
value)', then indexed properties are like 'T get_P(U index)' and 'void
set_P(U index, T value)', where U is the type of the indexer. And
indexed properties may have an arbitrary number of indexers.

and then again : how could I have
known? I still believe the documentation is not very clear on this
point. I want to figure out what can be expected of a property.

It should probably have been written as a pair of Get and Set methods.
Reading properties should ideally be cheap and a read-only operation. If
the operation is expensive, then a method call is more appropriate to
flag that fact.

-- Barry

--
http://barrkel.blogspot.com/