This project is read-only.

A rose by any other name might sell more

May 30, 2013 at 8:20 AM
Edited May 30, 2013 at 8:28 AM
I have a (very opinionated) observation - I hope it doesn't offend as it's well intended. :)

I think the name of this awesome library could be better.

To my thinking, it doesn't tell you what it does. It also makes it seem more UI specific than it really is - although I get this is a core usage scenrio, it's not all it can be.

I think if you renamed it to say, "DependencyTracker", it would get more traction.

I hope it does; it deserves it.

May 30, 2013 at 8:22 AM
Yeah, I'd second that. When I first saw the project name I thought: "Uh, another control library. I don't need that." But it turns out to be something very different (and more interesting).
May 30, 2013 at 1:06 PM
Edited May 30, 2013 at 1:08 PM
I ran an experiment a year ago. I released a library called KnockoutCS, which was really nothing more than a thin wrapper around Update Controls that made the syntax look like KnockoutJS. Admittedly, I haven't expanded support beyond Silverlight 5, but adoption and interest in that one hasn't indicated that the name really matters that much.

I named Update Controls back when it was just a library of Windows Forms controls that update themselves. With the addition of XAML, I no longer needed to override control classes like I do for Windows Forms. The Windows Forms library is still supported, BTW, and actually has pretty decent adoption.

The original name of the library was Mallardsoft.Dependency. It was offered as a product from my former consulting company, Mallard Software Designs. The idea was to have other libraries based on axioms of software behavior, including Mallardsoft.Ownership and Mallardsoft.Transaction. That name died when I went open source.

When I hear people talking about Steve Sanderson's KnockoutJS, they never mention the automatic dependency tracking. They always equate it to XAML data binding and MVVM, which are much weaker and based on the Observer Pattern. I don't believe that most devs recognize the advantages of automatic dependency tracking over Observer. So while I agree that that is the most interesting part of this library, calling it DependencyTracker would not tell the story.

When I hear the words "dependency tracking" used in conversation, the devs are always talking about package managers or build systems like Maven, Ruby Gems, NuGet, or NPM. The concept applies, but this particular library does not. So that name would be confusing.

Anyway, that's probably more information than you wanted to know. Keep the suggestions coming.
May 30, 2013 at 9:33 PM
Interesting points. I looked at the knockoutcs web site (and updatecontrols) because of your reference to them in the course.

My reaction to the knockoutcs site was that it didn't seem as feature-rich as update controls - from the example code on the site, I couldn't see how to do dependent properties with setters - which as you know from the setter thread is quite important to me.

You've made a good few points above the further suggest the experiment may have been unfair. But, I also think associating with knockoutjs doesn't really help explain the library and I doubt there are many people looking to move from JavaScript to Silverlight 5.

I think you are definitely on to something when you say the developers in general don't see the importance of automated dependency tracking - I can't recall hearing it discussed before seeing your course in a context like this, and I have 20 years of programming experience on MS technology.

I also think it takes a lot of experience to properly understand the implications. Look at your course - that's 5 hours long and it doesn't cut many corners to get to the point. I expect just the title looks quite scary to your average Pluralsight punter. It actually took me a while to get to it, and I was expecting it to be not much more than Code Contracts - I'm so glad I watched it all the way through (I 5-starred the course btw).

I think having more up to date samples on the site/blog would help - a lot of them use older iterations of the syntax which can be confusing. You're welcome to clean up and use the sample code I submitted for the bug if it's any use to you.

UpdateControls doesn't do enough to say what it does in its current incarnation. Maybe a descriptive name just isn't the way to go! Angular, Breeze, MooTools, etc... the kids today don't seem to like descriptive names!

Anyway, you've got one more fan to help spread the word here. Keep up to good work!
May 30, 2013 at 10:24 PM
Thanks for the great review of the course. Be on the lookout for my next one, coming soon!

I agree that I need to refresh the examples. Now I don't even use ForView.Wrap(), and instead favor using ViewModelLocatorBase.

BTW, you can set dependent properties in KnockoutCS. Pass a second lambda to KO.Computed. See the Selection example.

A non-descriptive name might be the way to go. Perhaps after finishing this course and refreshing the Update Controls examples, I'll run another experiment. I have some work based on portable class libraries that I haven't published yet. Maybe a fresh new library from that code base with a new name and a different API. People tend to get caught up on the whole Independent/Dependent thing. What do you think?
Aug 21, 2013 at 10:27 PM
Edited Aug 21, 2013 at 10:28 PM
There's a course?

I'd like to say, while I adore Update Controls conceptually and I'm sure it will take over the world someday, I am having significant problems in practice:
  1. Debugging - even with Uses and UsedBy, it can still be challenging to figure out why something isn't updating automatically, e.g. it's hard to tell what's going on inside UC's WPF code or which Dependents belong to which bindings.
  2. Runaway dependencies - it's easy to just let UC handle everything for you and forget about what's going on behind the scenes. The problem is that sometimes you inadvertently take dependencies which slow down the program. For example, I just implemented a new search function and somehow it got a dependency on an internal clock that updates every four seconds. I wouldn't have noticed except that the result listboxes showing the search results kept "resetting"*. In fact my entire program design is flawed, because updating certain things refreshes virtually everything, and I didn't notice because UC makes it so easy to ignore potential performance issues. In other words: UC made me a lazy person and now I regret it ;^). To make matters worse, UC does not support any way to stop change propagation (I understand why, and I even thought of a solution, but I didn't get around to implementing it.)
  3. Inefficient collection updates. Updating one property of one item in a collection refreshes everything that depends on that collection "from scratch". I've personally looked long and hard at this problem and... failed to find a solution. Sorry.
  4. Difficulty of offloading work to other threads. Most of the work in my program is done by Dependents in the ViewModels. Since Dependents on the UI thread actually trigger the updates, this work must be done synchronously on the UI thread. I haven't figured out how to offload the work to another thread without losing the convenience that UC provides. I can trigger updates of those Dependents on a second thread, sure, the problem is that there's nothing stopping the GUI thread from blocking itself by demanding updates to those same Dependents at the same time.
 * (There are other dependencies that also cause frequent "resets" too, so today I'm trying to figure out how to somehow prevent some listboxes from updating until the user manually asks for a refresh or modifies the search text; I haven't figured out how to accomplish this yet.)
Aug 21, 2013 at 10:39 PM
The course that Whirly refers to is "Provable Code" on Pluralsight. In one module, I look at how dependency tracking can help you prove that your code has the desired number of degrees of freedom.

You bring up some very good points. Perhaps we should start a thread or a defect for each one of them to discuss in more detail.
Aug 21, 2013 at 10:46 PM
Thanks, I will have a look at that course. Perhaps there should be a thread/defect for each of these, but I don't have solutions to propose. Except a solution for stopping change propagation ... sort of. I admit I let it leave my brain for too long and forgot the details.
Aug 21, 2013 at 10:51 PM
Wait, you have to pay to join the site? Do you get some of that, Micheal?
Aug 21, 2013 at 10:56 PM
Yes, Pluralsight pays its authors well. If you are interested in becoming an author, send me an email and I'll hook you up with the right folks. ( You can watch up to 200 minutes for 10 days prior to signing up. And I can get you a code for one month free.

Anyway, I don't want to make this a Pluralsight ad. But if you were to sign up, you might want to watch XAML Patterns, too. :)
Aug 21, 2013 at 11:18 PM
Edited Aug 21, 2013 at 11:19 PM
Do you get many viewers? I never heard of Pluralsight before today so I'm kinda puzzled how, if I made anything, anyone would end up watching it. Come to think of it, nah, I prefer to maximize viewers by giving information away. I always say there should be some kind of government program to pay people who want to create useful free software or free textbooks... otherwise it's a struggle to find enough time outside work.
Sep 6, 2013 at 4:23 PM
So, have you read my proposal on issue 9488?
Sep 6, 2013 at 9:19 PM
Sorry, I hadn't seen it. I need to adjust my email settings.

I'll take a look this weekend and see what I can work out.