All I have to say is wow! I know there's a lot of people out there who are going to attack this ferociously from every angle. After all, it's Microsoft, Novell and Mono, three entities that the OSS zealots love to attack. But still, I'm impressed by Microsoft's move. Instead of creating their own implementation that would compete with Moonlight, they actually endorse Moonlight as the OSS solution, and provide the needed collaboration to ensure compatibility. Bold move, and I think the people in charge of all of this deserve some kudos!
bdesmet wrote:It's a good question indeed but I do have a few concerns with the design of the properties you're describing. If setting one property causes another property's value to be changed as well, this is pretty much to be considered as a side-effect and maybe a property isn't the best choice in that case (in more complicated situations you'll have to make sure you're not causing a cycle in the chain of setter calls). For more info, check the Framework Design Guidelines on Choosing Between Properties and Methods.
Nevertheless, there's no silver bullet to this kind of problems - the one thing that's key is to be consistent. Concerning your WPF sample, I'd rely on the SelectedWidget property to become null automatically.
There are a million reasons properties would behave the way I described. Some simple examples:
DueDate and DaysPastDue. These are variations on the same data. A change to one thus is a change to the other. With little thought you can think of a lot of other examples that fall along these lines. For example, think of a Rectangle and the correspondance between the corner coordinates and the width and height.
When following the M-V-VM pattern, you'll typically have (for example) a Widgets collection and a SelectedWidget. A change to the Widgets collection can effect the SelectedWidget property. Those are just a few examples.
I'm not denying these are side effects, I'm denying the assertion that properties shouldn't have side effects.
Obviously the order should matter . But even from your description, I'm not certain that you've got the right order. Part of changing A is changing B. That means that B gets changed first.
I didn't want to spoil the discussion by stating my own thoughts, but maybe I should just spill it .
I think that setters should first ensure that all invariants are maintained, which means that events should probably fire after all changes to the object's state have been made. If that's the case, the order in which they fire is irrelevant at the source (the object), and only relevant at the target (the event listener), and it's wrong to assume any order at the target. Despite this, I think you should probably fire the events in the order in which the changes complete, so B fires before A.
This is a simple thing, that only in corner cases will probably be of any real concern. But it's the sort of thing always left out of consideration that gives me heart burn.
Imagine you have an object that implements INotifyPropertyChanged. One of the properties, say Foo, can be modified which will in turn modify another property, say Bar. In what order should the property change events fire (Foo followed by Bar or Bar followed by Foo), and why?
Somewhat related, let's imagine we're writing a ViewModel for our WPF application. We have a Widgets property and a SelectedWidget property. If we reassign the Widgets property, the WPF databinding will indirectly cause our SelectedWidget property to be set to null. Should be rely on this fact, or explicitly set the SelectedWidget to null in our Widget setter (which might (will?) cause a harmless redundant call)?
If you're really concerned, you could pick up a Raytec MT6 (or something similar) and check the temperature that way.
I got one for much less than that off eBay, but yeah, it is kind of a single purpose item.
The cool thing, though is to use it to monitor for hot zones in your case. Or to check out if you have a fever. Or aim it at a fish-tank and check the water temp. Or determine if your hamster is sleeping or dead.
LOL. Best post of the day.
Another use... check to see if that hamster is a "hamster from h3ll". (Obscure joke that no one will get unless they follow the link, but hey what's on the other side is fairly humorous on its own.)
Chinmay007 wrote:It's not a complete loss, but it can cause some issues:
1) Microsoft can revise the standard
1) Microsoft Office 2007 must be revised along with it, creating a possible mess with two different OOXML formats running around
2) Microsoft Office 2007 won't support standard ISO OOXML
I'm willing to bet most of the "comments" on the standard were looking for clarifications and more details, not actual changes that would impact the current Office. (For example, with heard the rumblings on here about "binary blobs" that are undocumented features for backwards compatibility with older Office formats. Fixing such an issue (if it exists) would only entail modifications to the document, and not any actual change to the existing format.) Even if there were changes required, you'd just be looking at a new version of Office and/or some service packs. As an XML format, if it's designed correctly, having multiple versions is a non-issue.
I have an E6600 that running the stock fan was idling at 50C. If left running, it would eventually creep up high enough to actually cause the PC to turn off. Under load it would kick off the alarms in PC Probe (it's on a P5B Deluxe Mobo) fairly reliably. I bought a better cooling system for it and it now idles around 40-42C and under load remains below 60C. I've never had to worry about temps before, so I have no idea how good/bad any of this is (though kicking off alarms and powering down indicates the stock cooling system was obviously not "good enough"). But based on my temps, that 70C sounds high?
Now the only issue I have with heat is that though the PC is running within ranges PC Probe considers tolerable, I've now raised the temperature in the room by nearly 5F. Room is just plain stuffy!
Are you talking about performance as in "stability"? I've nothing but problems with Internet Explorer's stability since IE4. Can't count how many times I have gotten "Internet Explorer illegal operations" over the years. Likely more then any other application. I was a very early adopter of Firefox because of this and the massive security/spyware problems. I don't use Internet Explorer 7 enough to judge it specifically, but why should I? Firefox works perfectly for me and has more (relevent) features.
I'm not going to make any assumptions about it's codebase however. To me the final product is what matters, and Internet Explorer loses in this respect.
We'll have to agree to disagree. I've never had stability issues with IE. I can't say the same for FF. If nothing else, the memory leaks were enough to get me to switch back as soon as IE 7 came out. I had several other stability issues with FF beyond the leaks as well.
Mozilla is actually what killed them. The Mozilla products were pure trash. Firefox was the first usable browser. But I don't think it's likely to remain popular either. The underlying code base is just not of high enough quality, IMHO.
I've seen the Firefox source, on the whole it looks fine to me; if a little hard to understand initally (just like any other software project really). The only failing is that it needs more documentation.
I've done more than see it. I've worked with it. For nearly 3 years. It's the only Open Source code I've worked with that I truly don't have a good opinion of.