|
I'd question perhaps how maintainable that is though!
|
|
|
|
|
I don't even know the code that belongs to and it is rather easy to see what it does. It needs a delegate to invoke back to the GUI thread from within the runner thread. As an exercise, convert that code to a non-anonymous delegate way, you will see the resulting code will be much more disconnected, and a lot more verbose. Unless he is repeating the code anywhere else, I see no reason to refactor it.
|
|
|
|
|
leppie wrote: you will see the resulting code will be much more disconnected
Certainly, however convert it to the .NET 1.0 way and it'll be far less confusing.
|
|
|
|
|
Derek Bartram wrote: I'd question perhaps how maintainable that is though!
The more I think about it, the more I find the answer is very.
All the code is in one place, and isn't abomnably long.
At worst it could be said that the threaded method should be declared rather anonymous, the others are just what anonymous methods were intended for.
I'm largely language agnostic
After a while they all bug me
|
|
|
|
|
|
I just found a bunch of properties made read-only like this (I think they're from a template):
set
{
}
Huh? If you want it to be read-only, make it read-only!
|
|
|
|
|
That's not so much read-only as it is a "la la la I'm not listening la la la" property.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means?
|
|
|
|
|
Actually, I have found that sometimes you need to do that.
I can't remember the exact reasoning, but a couple weeks ago I was trying to pass a readonly property to a .NET function of some sort and it would throw an error, despite, the property not being written too...the "fix" was to have an empty set...and I believe I marked it as deprecated so it threw a compile error if someone tried to write to it.
|
|
|
|
|
The ObsoleteAttribute can't be applied to a property accessor.
The class in question is implementing an abstract class, which specifies both get and set. I should have checked that before I posted this, but still... the set should throw a NotImplementedException or something. Failing that, the accessor should be functional.
|
|
|
|
|
Well, if the guy who owns the interface doesn't want to remove the set from the interface, I guess you are pretty much stucked with that.
|
|
|
|
|
Yes, but silently ignoring the value is poor style.
|
|
|
|
|
PIEBALDconsult wrote: silently ignoring the value is poor style.
Yes, it is. I can only imagine the headache of trying to track it down on a Friday afternoon.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
|
|
|
|
|
Well, personally I say get rid of properties anyway! There is simply no point in them other than making the language more bloated and less clear.... In the good old days....
.name = public class variable, didn't run any code, just gave access.... now will it run code, or won't it!?!?!??!?
|
|
|
|
|
Sure they can be abused, but I wouldn't get rid of them just because of that.
|
|
|
|
|
Maybe, but it just seams like a lazy way of coding that means it's harder to tell what code is actually doing. Personally I feel it makes using other people's code harder (particularily badly written code where the property name is misleading)
|
|
|
|
|
But properly written properties do data validation, and will modify any other values that need to be modified when that property changes.
|
|
|
|
|
That's the problem though... the amount of people who i've seen doing things like modify data structures in property gets, is pretty high. Why leave elements of the language that can result in really hard to debug code and misconceptions?
|
|
|
|
|
But, often, if you don't modify the data of the class, when you set the property, your data may be invalid...and calling functionX at that time will result in invalid results, or errors.
|
|
|
|
|
Yes, but it leads to misconceptions about what the code does. I suppose it all comes down to good code documentation perhaps
|
|
|
|
|
...to a sufficiently motivated/determined idiot. No useful language can enforce a fixed floor for intelligence or sensibility of its (ab)user. Languages that make significant efforts in those directions, like Logo or Wirth's original Pascal, find themselves compartmentalised and marginalised safely out of the way of any Real Programmers™.
You can't effectively use language semantics to guard against process failure. The entire reasoning for practices like XP pair programming, test-driven development that requires every bit of code to be tested, and so on is precisely to guard against such ingenious stupidity.
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
No useful language is idiot-proof...
But languages can be FOR idiots..... *see Java
|
|
|
|
|
Java, as originally conceived (J2SE, that is) is a perfectly decent language for several different problem domains, including particularly those similar to that for which it was created. The idiocy comes from two things. First, the "Java should do everything including the kitchen sink" mentality that gave us J2ME and (good working definition of "coding horror") J2EE. Secondly, the dishonest marketing commonly associated with the infinite battalions of H1B coders who have perfectly good-sounding (though mass-mimeographed) "qualifications" but couldn't solve a problem in Java (or apparently anything else) if you gave them a flashlight, a map, all the textbooks they could carry and a two-year head start. But they're the fashion, so thousands of lemmings cleverly disguised as "software-using companies" are throwing themselves of the cliff. (It's a little late to realize that you need an exit strategy when you've already been accelerating at 10 m/sec/sec for two or three minutes....)
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
Jeff Dickey wrote: Java, as originally conceived (J2SE, that is) is a perfectly decent language for several different problem domains, including particularly those similar to that for which it was created.
Out of curiosity what domains it is better suited for?
Personally i've only ever see the advantage of Java being for mobile and cross platform applications, something I see in the second case as being of limited value.
|
|
|
|
|
I'd say small, embedded systems like set-top boxes or microwave ovens or TiVos or suchlike....close enough to the original problem domain addressed by what eventually became J2SE 1.0, without all the EE or additional-API BS-cleaverly-disguised-as-APIs. When Java was hijacked from scratching-an-itch to become the cornerstone of the One "True" Programming Religion, with hundreds of thousands of low-cost, mass-produced "proessionals", the nice, more-or-less-forward progress of software discovery and evolution took a nasty, twisted turn. For many shops controlled by Javacolytes, that 'twisted turn' has straightened out nicely. They're under a constant acceleration of ten meters per second per second...
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
Still, its better then the following
private int m_iData;
public int Data
{
get
{
return m_iData;
}
set
{
int iOldData = m_iData;
m_iData = value;
m_iData = iOldData
}
}
codito ergo sum
|
|
|
|