@property - take it behind the woodshed and shoot it?

[Adam Wilson]

On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return  
> value taking (), the () go on the return value.
>
> 2. the:
>     f = g
> rewrite to:
>     f(g)
> only happens if f is a function that only has overloads for () and (one  
> argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

I want to point out another usage of properties that invades my work every  
day. Consider:

public partial class CustomerXAML : DependencyObject
{
	public Guid ID { get { return (Guid)GetValue(IDProperty); }  set {  
SetValue(IDProperty, value); } }
	public static readonly DependencyProperty IDProperty =  
DependencyProperty.Register("ID", typeof(Guid), typeof(CustomerXAML),  
null);
}

Where:

public class DependencyObject
{
	public object GetValue(DependencyProperty prop);
	public void SetValue(DependencyProperty prop, object value);
}

What does this code say? I am dealing with data or calling a function?  
Well to those of you not familiar with WPF/XAML's Dependency pattern let  
me explain. You're doing both.

You see XAML uses something that for lack of a better term I will call a  
"sparse memory model". Another way to describe it is to say that the  
DependencyObject stores ONLY the values that have been changed from the  
default value. They had to do this because their object model is  
ridiculous and they needed over a gigabyte of RAM just to instantiate all  
the objects required to draw an empty window. They discovered that most of  
the values in the object didn't change from the defaults.

However, the changes had to be stored in a Dictionary (think Map) for  
speed, that's what all the typeof's in the Register function are for. And  
storing/retrieving those directly from the Map would have lead to all  
sorts of problems. So GetValue/SetValue handle that for you and allows  
them to do much more, like databinding and update callbacks.

My point is this. This does not violate encapsulation, we ARE working with  
just DATA, but we want to hide the implementation details of HOW we are  
working with said data, and in this case we CANNOT use a simple backing  
field. From a user perspective CustomerXAML.ID is JUST data FIELD. But  
behind the scenes it's a bit more complicated than that.

THAT is the power of properties.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/