On Thu, 17 May 2012 07:44:12 -0700 (PDT), Dom wrote:
> I guess I don't really understand how "override" works with
> properties. [...]
Short version: declaring the property with "override" causes the two
property methods (the getter and the setter) to each themselves be
overrides of the base property methods.
> [...]
> Some problems:
> 1. I know from debugging that when the setter is called, it in turn
> calls the getter. Why?
I haven't looked at the code, but one obvious explanation is that the
implementation may compare the new value with the current value, so that
certain things happen only when the value actually changes.
> 2. If in the immediate window I request base.SelectedItem, it calls
> the getter. Why? I thought it would only call the getter if I
> requested this.SelectedItem.
Because you only get non-virtual dispatch for the method you're actually
in. I'm a little surprised the debugger even allows "base.SelectedItem" to
be retrieved while the setter is the current method, but given that it
does, it's still not that surprising to me that you'd still get the fully
virtual dispatch of the method.
> 3. Since base.SelectedItem calls the getter, and the getter calls
> base.SelectedItem, why am I not caught in an infinite loop?
That's too imprecise a question to answer. There is no "base.SelectedItem"
per se. When you declare a property, you wind up with two methods in the
type. For example, "get_SelectedItem" and "set_SelectedItem".
Infinite loops certainly are a risk, but the getter shouldn't be calling
the setter, so even if the setter calls the getter, that wouldn't cause an
infinite loop. Similarly, using "base.SelectedItem" to achieve non-virtual
dispatch calls a different method than yours; as long as that doesn't in
turn wind up calling your own implementation again (and why would it?),
again no infinite loop.
Pete