FUTURE POSTS
- Expertise in the age of AI, or: Matt's Claude'll handle this - about one day from now
- 15+ years of working with coding agents - 6 days from now
- Putting Claude up against our test suite - 8 days from now
- The GPU Is the New Bangalore - 10 days from now
- Learning to code, 1990s vs 2026 - 14 days from now
There are posts all the way to May 05, 2026
Comments
Interesting catch
Who has the mistake?
Both can be argued to be correct.
The problem is not that, it is that there is a difference.
So now that the source to the CLR is viewable by the public, how does that impact the mono project and future versions I wonder?
Same as always, if you look at CLR code, please don't contribute to Mono
Mono is correct because it does not use crappy "m_" prefixing for member types. ;)
Shoot! Now that I've glanced at this post, I can't go fix this bug for you! AARGH! My eyes! ;)
Maybe you should have put a spoiler warning on this for any mono devs. I wouldn't be surprised if some were among your readers.
This did not come from the CLR sources. This is a reflector output.
Beside, I frankly doubt that anyone will reveal the secret of PROPERTY GETTERS
@Hanselmen, don't worry the mono team has an official eye bleach for just this sort of situation.
gotta get one of those: http://www.youtube.com/watch?v=c7vqvdwkvJk&NR=1
Good catch :) So what does CheckDisposed() do? throw an exception if the object is disposed?
I ran into a few things like this when working with Mainsoft (which uses Mono source to cross compile to java with their compiler).
By the way, what do you use to create your diagrams?
Firefly,
Yes
Jarrod,
PowerPoint
We only use m_ names when we are forced by something like remoting (which likes to send reflection-based internal field names across the wire).
Otherwise we stay away from that horrible practice.
Miguel
Comment preview