On Thu, 24 Jan 2013 00:34:42 -0800, Walter Bright
<newshou...@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/
