471,349 Members | 1,846 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,349 software developers and data experts.

What is good syntax for instanating virtual types?

Is this 'good' code to debug?

//Create separate Type library
namespace Common
{
public sealed class Statuses
{
internal Statuses(){}
public sealed class Good
{
public const string Ok = "Ok";
}
public sealed class Bad
{
public const string NotOk = "NotOk";
}
}
}
// end

// Create simple console app to use library
using Common;
namespace ConsoleApplication1
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
string tmp = "Ok";
bool isOk = String.Compare(tmp, Statuses.Good.Ok) == 0;
Console.WriteLine(isOk.ToString());
}
}
}
Jun 27 '08 #1
4 1140
On Thu, 29 May 2008 16:25:00 -0700, jsh02_nova
<js*******@discussions.microsoft.comwrote:
Is this 'good' code to debug?
I don't even understand the question. Looking just at your subject, the
answer is "there's no such thing as a 'virtual type'". Looking at the
code, I'd have to say "no, that's not good code". For one, I don't see
the point of the nested classes "Ok" and "NotOk". They seem like a
pointless redundancy to me.

If you can be more clear about your question -- what is it that you think
a "virtual type" is, and what specific goal do you have in mind that
you're trying to address -- maybe a better answer would be forthcoming. :)

Pete
Jun 27 '08 #2
I do not know what you are targetting!!

However what ever the code you wrote is not good!! Try refactoring it
to an enum

namespace ConsoleApplication1
{
public enum Statuses
{
Ok, NotOk
}

class Class1
{
[STAThread]
static void Main(string[] args)
{
string tmp = "Ok";
bool isOk = String.Compare(tmp, Statuses.Ok.ToString())
== 0;
Console.WriteLine(isOk.ToString());
}
}
-Cnu

On May 30, 4:25*am, jsh02_nova <jsh02n...@discussions.microsoft.com>
wrote:
Is this 'good' code to debug?

//Create separate Type library
namespace Common
{
* * public sealed class Statuses
* * {
* * * * *internal Statuses(){}
* * * * *public sealed class Good
* * * * *{
* * * * * * * public const string Ok = "Ok";
* * * * *}
* * * * *public sealed class Bad
* * * * *{
* * * * * * * public const string NotOk = "NotOk";
* * * * *}
* * }}

// end

// Create simple console app to use library
using Common;
namespace ConsoleApplication1
{
* * *class Class1
* * *{
* * * * * [STAThread]
* * * * * static void Main(string[] args)
* * * * * {
* * * * * * * string tmp = "Ok";
* * * * * * * bool isOk = String.Compare(tmp, Statuses.Good.Ok) == 0;
* * * * * * * Console.WriteLine(isOk.ToString());
* * * * * }
* * *}

}- Hide quoted text -

- Show quoted text -
Jun 27 '08 #3
The exercise was try to refactor multiple 'hard coded' string comparisons
into nested abstract types with public readonly string fields, using .Net
v1.1. These 'abstract' types would be used throughout the solution. 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.
Jun 27 '08 #4
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
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Just Me | last post: by
4 posts views Thread by moleskyca1 | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.