On Fri, 30 May 2008 15:58:00 -0700, jsh02_nova
<js*******@discussions.microsoft.comwrote:
The exercise was try to refactor multiple 'hard coded' string comparisons
into nested abstract types with public readonly string fields, using .Net
v1.1.
Why? Why is that the goal? The code you posted seems to achieve that,
but why do you want code that looks like that?
These 'abstract' types would be used throughout the solution.
There's nothing abstract about those types. In fact, by virtue of being
"sealed", it's the exact opposite.
It was
discovered that the VS 2003 IDE couldn’t 'debug' these nested types, but
it
could be seen that their instances were being created by the CLR. So, the
String.Compare method was working but the VS 2003 IDE wouldn’t hold these
nested ‘sealed’ types in scope so that the types could be 'watched' in
the
debugger.
Why would you want to "watch" a constant? Did you think it was going to
change? How does putting constants in a nested class address the issue?
I'm not even sure I've used the 2003 version of VS...I might have jumped
straight from VC6 to 2005. I'm not sure what limitations might exist in
the debugger that would present a problem here. But it seems to me that
if you're having trouble with the tools, the most appropriate solution is
to upgrade the tools, rather than try to rearrange your code in a
contrived way.
Pete