It's also more than just refactoring - requirements change; instead of binding 
to this property, you are now binding to this other property, or to a different 
object altogether. The problem with the way binding is setup both in 
Silverlight, WPF and WinForms is that you don't find out about these things 
until runtime. In the Silverlight/WPF case binding to a non-existent property 
doesn't even cause  a runtime failure - you need to look at tracing to see 
these. 

An example of how easy this is miss; attach to Visual Studio to itself and see 
how binding failures there are from WPF. Had they used something similar to 
below, they would have found these problems as soon they hit the compile 
button. 
 
-----Original Message-----
From: silky [mailto:[email protected]] 
Sent: Wednesday, May 26, 2010 5:23 PM
To: David Kean
Cc: ozDotNet
Subject: Re: ASP.NET Control databinding, member properties, dynamically fetch 
property name?

On Thu, May 27, 2010 at 10:15 AM, David Kean <[email protected]> wrote:
> It's not for variable names, it's for properties and methods. I have 
> to refactor code all the time - I'm not smart enough to get it right the 
> first time.

I don't understand this. Why make it like some sort of joke that I'm somehow 
smart enough to get it right. Or that it's something unachievable or 
ridiculous. This attitude doesn't make sense to me.
I'm no smarter than anyone else, and it doesn't take a rocket surgeon to choose 
a good name for something.


> When you think about it, it's really just a nature extension to 
> typeof. We don't hard code type names, so why hard code member names?

To be honest, I rarely find myself writing these types of names in strings 
anyway. It's almost always in the markup, and sometimes it isn't, but in that 
case I suppose I wouldn't be particularly upset if it was done in the fashion 
you've shown, but I just wouldn't be concerned either way.

I don't think it's particularly stupid anymore, just not particularly 
neccessary. I don't really have strong feelings about it.

--
silky

  http://www.programmingbranch.com/

Reply via email to