FUTURE POSTS
- Partial writes, IO_Uring and safety - about one day from now
- Configuration values & Escape hatches - 4 days from now
- What happens when a sparse file allocation fails? - 6 days from now
- NTFS has an emergency stash of disk space - 8 days from now
- Challenge: Giving file system developer ulcer - 11 days from now
And 4 more posts are pending...
There are posts all the way to Feb 17, 2025
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