Is Class Synonymous with Type?

[garyusenet]

I'm using an example piece of code: -
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}

[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);

private Sound(){}
}

enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}
In the right up one part of explanation states. "Starting from the top,
you will notice that an entire type named Sound is devoted to
MessageBeep. If I need to add support for playing waves using the
Windows API function PlaySound, I could reuse the Sound type. However,
I am not offended by a type that exposes a single public static method.
"

Now i thought a type was a classifcation of variable, and a Class was a
blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

or does type simply mean the same thing as class?

Thanks,

Gary-

[Brian Gideon]

ga********@myway.com wrote:

I'm using an example piece of code: -
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}

[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);

private Sound(){}
}

enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}
In the right up one part of explanation states. "Starting from the top,
you will notice that an entire type named Sound is devoted to
MessageBeep. If I need to add support for playing waves using the
Windows API function PlaySound, I could reuse the Sound type. However,
I am not offended by a type that exposes a single public static method.
"

Now i thought a type was a classifcation of variable, and a Class was a
blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

or does type simply mean the same thing as class?

Thanks,

Gary-

Gary

Yes, a class and a type are similar concepts. A class is the mechanism
you use in C# to create a new type.

Brian

[Peter Bradley]

A class defines a type. So it's a type of type. An int is another type of
type. Structs and Enums are other types of types. Structs, Enums and
classes are examples of user-defined types. Ints, floats, longs etc are
examples of native types.

Less facetiously, a type is (simplistically) an area of memory that the
runtime treats as a single thing. Objects are instances of reference types
(you only ever get a pointer to them). Structs and native types like ints
are value types (variables of these types are labels for the first address
location associated with the value).

If all I've done is confuse you still further, please let me know and I'll
try again at more length.
Peter

<ga********@myway.comwrote in message
news:11**********************@16g2000cwy.googlegro ups.com...

I'm using an example piece of code: -
namespace Wintellect.Interop.Sound{
using System;
using System.Runtime.InteropServices;
using System.ComponentModel;

sealed class Sound{
public static void MessageBeep(BeepTypes type){
if(!MessageBeep((UInt32) type)){
Int32 err = Marshal.GetLastWin32Error();
throw new Win32Exception(err);
}
}

[DllImport("User32.dll", SetLastError=true)]
static extern Boolean MessageBeep(UInt32 beepType);

private Sound(){}
}

enum BeepTypes{
Simple = -1,
Ok = 0x00000000,
IconHand = 0x00000010,
IconQuestion = 0x00000020,
IconExclamation = 0x00000030,
IconAsterisk = 0x00000040
}
}
In the right up one part of explanation states. "Starting from the top,
you will notice that an entire type named Sound is devoted to
MessageBeep. If I need to add support for playing waves using the
Windows API function PlaySound, I could reuse the Sound type. However,
I am not offended by a type that exposes a single public static method.
"

Now i thought a type was a classifcation of variable, and a Class was a
blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

or does type simply mean the same thing as class?

Thanks,

Gary-

[Dustin Campbell]

Now i thought a type was a classifcation of variable, and a Class was

a blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

All classes are types but not all types are classes. In C#, a type could be:

1. Class
2. Interface
3. Struct
4. Enum
5. Delegate

Any of these can be used to classify a variable. For example:

class Employee { }

private void TestEmployee()
{
// Here is a variable whose type is a class.
Employee emp = new Employee();
}

Best Regards,
Dustin Campbell
Developer Express Inc.

[Brian Gideon]

Brian Gideon wrote:

Yes, a class and a type are similar concepts. A class is the mechanism
you use in C# to create a new type.

Err...a class is *a* mechanism for creating a new type. It's not *the*
mechanism.

[Oliver Sturm]

Hello,

In addition to what others have already mentioned, you should also be
aware that in .NET there's actually a class called Type, which is (not
surprisingly) used to hold information about a type. Basically .NET lets
you analyze types and other language elements at runtime using a process
known as Reflection, and the information resulting from this analysis is
sometimes stored in classes of type Type. I'll stop now before I sound
like a Monty Python parody :-)
Oliver Sturm
--
http://www.sturmnet.org/blog

[garyusenet]

Thankyou all very much. It is quite a lot clearer now thankyou.

One question though. At the moment (i hope i haven't misunderstood) My
understanding is that all types are ultimately defined in a class.
'native types' already have their classes defined, and user types are
defined by individual users in new classes.

But it was said in this thread that a class, is a type of type.

So i guess my understanding must still be a bit flawed, for if a type
is defined by a class, and a class is a type of type, the class type
would have to be defined in a class and we would have an infinite
amount of classes each defining each other.

Can someone clarify this for me please?

Thankyou

[Peter Bradley]

Remember not all types are classes. Native types are just that. Native
types. They are not classes (unless they've been converted into special
classes, by boxing for example). They are ints, floats, doubles, bytes etc
etc. - and nothing else.

Similarly Structs are not classes. They are structs. Structs are another
type of type: user defined value types, as it happens. As someone else has
pointed out, there are also enumeration types, delegate types, interface
types, even Type types.

In this respect, C# is not completely OO. For that you have to look at
something like Smalltalk, where everything is a class (or a meta class) - or
an object, of course. Java sort of goes part way by defining classes that
encapsulate the native types. C# does something similar with boxing.

Remember, a type, when instantiated, is just a bit of memory defined either
by a reference (pointer) for reference types, or a label for value types.

Languages do not have to be OO to have types. C is not OO and has types.
The type is what you put before a variable when you declare it:

int i;
float f;
char* s;

The above declare three variables in C of type int, float and pointer to
char respectively.

You do pretty much the same sort of thing in C#:

int i;
float f;
string s;

Post again if you're still confused.
HTH
Peter
The same goes for Enums, Delegates and all the other things that have been
mentioned.
<ga********@myway.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

Thankyou all very much. It is quite a lot clearer now thankyou.

One question though. At the moment (i hope i haven't misunderstood) My
understanding is that all types are ultimately defined in a class.
'native types' already have their classes defined, and user types are
defined by individual users in new classes.

But it was said in this thread that a class, is a type of type.

So i guess my understanding must still be a bit flawed, for if a type
is defined by a class, and a class is a type of type, the class type
would have to be defined in a class and we would have an infinite
amount of classes each defining each other.

Can someone clarify this for me please?

Thankyou

[Oliver Sturm]

I think the statement "a class is just one particular type of type" refers
to the fact that there are other "things" that can also referred to as
types. Like structs, for example, which are so-called "value types" in
..NET, and are not classes.

To be honest, I do think that the assessment "a class is very similar to a
type" is correct for many intents and purposes. It's not technically
perfect, but it brings the point across pretty well :-)

As an example, when you read literature about object oriented programming,
you may sometimes find people refer to classes and objects, with the
important difference being that objects are instances of classes. So the
class is basically the declaration of something, while the object is the
actual incarnation of it. And in this sense, a type is really very similar
to a class - it describes something in detail, something that doesn't
actually have to exist at that point. Technically speaking, that thing
that is being described might not be a class after all, that's where the
disagreement comes in.
Oliver Sturm
--
http://www.sturmnet.org/blog

[garyusenet]

Thanks again I've got an enormous amount out of your kind explanations.
One last question on the subject from me!

If native types aren't defined in classes where are they defined? For
instance when I try to assign a value greater than
18,446,744,073,709,551,615 to a long condition variable as part of a
for loop. It is underlined in red and if I hover over it i'm told that
my Intergral constant is too large.

e.g.
for (i = 0; i < 99999999999999999999; i++)

Where is it actually written that I cant assign a value this large to a
long?

The reason i thought every type would be defined in a class is i
thought then the constructor could have some code to check the size of
the value being assigned. But if this isn't the case, where does this
logic take place?

Thanks again!

Gary-

[Kevin Spencer]

Actually, all managed types ARE classes.

Interface, struct, enum all inherit the System.ValueType class, which
inherits System.Object. The following is a list of all types that inherit
System.ValueType:

http://msdn2.microsoft.com/en-gb/lib...77(VS.71).aspx

System.Delegate is simply a class which inherits System.Object.

Therefore, a type and a class are synonymous in the .Net Framework.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>Now i thought a type was a classifcation of variable, and a Class was
a blueprint for a real world thing. Can you tell me am i confusing two
meanings of type here?

All classes are types but not all types are classes. In C#, a type could
be:

1. Class
2. Interface
3. Struct
4. Enum
5. Delegate

Any of these can be used to classify a variable. For example:

class Employee { }

private void TestEmployee()
{
// Here is a variable whose type is a class.
Employee emp = new Employee();
}

Best Regards,
Dustin Campbell
Developer Express Inc.

[Kevin Spencer]

So-called "Native Types" (int, double, struct, enum, etc) ARE classes, which
inherit System.ValueType, which inherits System.Object. See:

http://msdn2.microsoft.com/en-gb/lib...77(VS.71).aspx
http://msdn2.microsoft.com/en-gb/lib...pe(VS.71).aspx

ALL types are classes. And all classes are types.

And in this respect, C# (and more importantly, the CLI) is COMPLETELY OO.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

"Peter Bradley" <pb******@uwic.ac.ukwrote in message
news:uE**************@TK2MSFTNGP04.phx.gbl...

Remember not all types are classes. Native types are just that. Native
types. They are not classes (unless they've been converted into special
classes, by boxing for example). They are ints, floats, doubles, bytes
etc etc. - and nothing else.

Similarly Structs are not classes. They are structs. Structs are another
type of type: user defined value types, as it happens. As someone else
has pointed out, there are also enumeration types, delegate types,
interface types, even Type types.

In this respect, C# is not completely OO. For that you have to look at
something like Smalltalk, where everything is a class (or a meta class) -
or an object, of course. Java sort of goes part way by defining classes
that encapsulate the native types. C# does something similar with boxing.

Remember, a type, when instantiated, is just a bit of memory defined
either by a reference (pointer) for reference types, or a label for value
types.

Languages do not have to be OO to have types. C is not OO and has types.
The type is what you put before a variable when you declare it:

int i;
float f;
char* s;

The above declare three variables in C of type int, float and pointer to
char respectively.

You do pretty much the same sort of thing in C#:

int i;
float f;
string s;

Post again if you're still confused.
HTH
Peter
The same goes for Enums, Delegates and all the other things that have been
mentioned.
<ga********@myway.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

>Thankyou all very much. It is quite a lot clearer now thankyou.

One question though. At the moment (i hope i haven't misunderstood) My
understanding is that all types are ultimately defined in a class.
'native types' already have their classes defined, and user types are
defined by individual users in new classes.

But it was said in this thread that a class, is a type of type.

So i guess my understanding must still be a bit flawed, for if a type
is defined by a class, and a class is a type of type, the class type
would have to be defined in a class and we would have an infinite
amount of classes each defining each other.

Can someone clarify this for me please?

Thankyou

[Dustin Campbell]

Actually, all managed types ARE classes.

Yes, I'm aware of that. However, I was listing the various kinds of types
that can be defined in C#.

Interface, struct, enum all inherit the System.ValueType class, which
inherits System.Object. The following is a list of all types that
inherit System.ValueType:

Interface does not inherit from System.ValueType.
Structs do inherit from System.ValueType.
Enums inherit from System.Enum -- which inherits from System.ValueType.

System.Delegate is simply a class which inherits System.Object.

Delegates actually decend from System.MulticastDelegate -- which descends
from System.Delegate.

Therefore, a type and a class are synonymous in the .Net Framework.

I was attempting to demonstrate the difference in C# -- not the .NET framework.
It is true that everything eventually descends from System.Object and, in
metadata is a class. However, I'm not sure that's relevant here since the
discussion is about C#. So, re-worded for clarity:

All C# classes are .NET types but not all .NET types are C# classes.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Peter Bradley]

In the standard.

The language infrastructure takes care of it all for you for native types.
For example it knows that a signed int32 is 32 bits, each representing a
power of 2, with the leftmost bit representing the sign (IIRC). For floats
and doubles it knows all about mantissas and exponents.

For non-class-based user defined types, like structs, you do at least a part
of it when you define the struct (or whatever). What you are doing is
telling the language infrastructure how much memory it needs to allocate for
this particular type of datastructure, whether it needs to allocate it on
the stack (value types) or the heap (reference types), and how that block of
memory is logically divided. The infrastructure knows how to reference the
various parts of instances of the data type you've defined. Once again,
it's in the standard and relies on you following the syntax of the language
for it to work (e.g. using dot notation for structs).

HTH (and keep asking questions if you're interested)
Peter

<ga********@myway.comwrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

Thanks again I've got an enormous amount out of your kind explanations.
One last question on the subject from me!

If native types aren't defined in classes where are they defined? For
instance when I try to assign a value greater than
18,446,744,073,709,551,615 to a long condition variable as part of a
for loop. It is underlined in red and if I hover over it i'm told that
my Intergral constant is too large.

e.g.
for (i = 0; i < 99999999999999999999; i++)

Where is it actually written that I cant assign a value this large to a
long?

The reason i thought every type would be defined in a class is i
thought then the constructor could have some code to check the size of
the value being assigned. But if this isn't the case, where does this
logic take place?

Thanks again!

Gary-

[Peter Bradley]

Nice one. Thanks
Peter

"Kevin Spencer" <sp**@uce.govwrote in message
news:O%****************@TK2MSFTNGP02.phx.gbl...

So-called "Native Types" (int, double, struct, enum, etc) ARE classes,
which inherit System.ValueType, which inherits System.Object. See:

http://msdn2.microsoft.com/en-gb/lib...77(VS.71).aspx
http://msdn2.microsoft.com/en-gb/lib...pe(VS.71).aspx

ALL types are classes. And all classes are types.

And in this respect, C# (and more importantly, the CLI) is COMPLETELY OO.

--
HTH,

Kevin Spencer
Microsoft MVP
Logostician
http://unclechutney.blogspot.com

There is a madness to my method.

"Peter Bradley" <pb******@uwic.ac.ukwrote in message
news:uE**************@TK2MSFTNGP04.phx.gbl...

>Remember not all types are classes. Native types are just that. Native
types. They are not classes (unless they've been converted into special
classes, by boxing for example). They are ints, floats, doubles, bytes
etc etc. - and nothing else.

Similarly Structs are not classes. They are structs. Structs are
another type of type: user defined value types, as it happens. As
someone else has pointed out, there are also enumeration types, delegate
types, interface types, even Type types.

In this respect, C# is not completely OO. For that you have to look at
something like Smalltalk, where everything is a class (or a meta class) -
or an object, of course. Java sort of goes part way by defining classes
that encapsulate the native types. C# does something similar with
boxing.

Remember, a type, when instantiated, is just a bit of memory defined
either by a reference (pointer) for reference types, or a label for value
types.

Languages do not have to be OO to have types. C is not OO and has types.
The type is what you put before a variable when you declare it:

int i;
float f;
char* s;

The above declare three variables in C of type int, float and pointer to
char respectively.

You do pretty much the same sort of thing in C#:

int i;
float f;
string s;

Post again if you're still confused.
HTH
Peter
The same goes for Enums, Delegates and all the other things that have
been mentioned.
<ga********@myway.comwrote in message
news:11*********************@f1g2000cwa.googlegro ups.com...

>>Thankyou all very much. It is quite a lot clearer now thankyou.

One question though. At the moment (i hope i haven't misunderstood) My
understanding is that all types are ultimately defined in a class.
'native types' already have their classes defined, and user types are
defined by individual users in new classes.

But it was said in this thread that a class, is a type of type.

So i guess my understanding must still be a bit flawed, for if a type
is defined by a class, and a class is a type of type, the class type
would have to be defined in a class and we would have an infinite
amount of classes each defining each other.

Can someone clarify this for me please?

Thankyou

[Marc Gravell]

Well, I think that depends on your definition of class; the runtime, for
instance, doesn't agree:

struct MyStruct { }
static void Main()
{
Console.WriteLine(typeof(MyStruct).IsClass);
}

(note: using a custom struct just for illustration; also applies to Int32
etc)

Marc

[Marc Gravell]

(ignore my last post; re-reading your post, it might just be wording that we
are tripping over here...)

Marc

[Dustin Campbell]

ALL types are classes. And all classes are types.

However, that statement simply confuses C# developers because the next questions
are often: "so what's a struct? Is that a class too? Then, why don't I declare
it with the 'class' keyword?"

While all types are .NET classes that descend from System.Object (excepting
System.Object itself) is completely true on the metadata-level, the CLR does
not treat all types the same and it is important to make distinctions between
value types and reference types. Because if you don't, the simply confuse
the novice C# developer later.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Dustin,

>ALL types are classes. And all classes are types.

However, that statement simply confuses C# developers because the next
questions are often: "so what's a struct? Is that a class too? Then, why
don't I declare it with the 'class' keyword?"

ValueType adds additional semantics to classes. Using "struct" instead of
"class" tells the C# compiler that you would like to use those additional
semantics (and behavior) in your class, type, object - whatever. "enum"
does something similar, but to structures (value-types, which are also
classes, types and objects - whatever :), etc.

While all types are .NET classes that descend from System.Object
(excepting System.Object itself) is completely true on the metadata-level,
the CLR does not treat all types the same and it is important to make
distinctions between value types and reference types. Because if you
don't, the simply confuse the novice C# developer later.

I agree that the distinction is important, but I think it's the distinction
itself that commonly confuses novice developers regardless of whether it
becomes apparent sooner or later in their exploration of C#. Though, I
think that making these distinctions later allows novices to focus on syntax
and grammar, which should definitely come first, IMO. As soon as they ask,
"What's a struct?", as you put it, or, "Where did the value of this variable
go?", that's when a conversation such as this should take place :)

--
Dave Sexton

[Dustin Campbell]

>>ALL types are classes. And all classes are types.

>>>

However, that statement simply confuses C# developers because the
next questions are often: "so what's a struct? Is that a class too?
Then, why don't I declare it with the 'class' keyword?"

ValueType adds additional semantics to classes. Using "struct"
instead of "class" tells the C# compiler that you would like to use
those additional semantics (and behavior) in your class, type, object
- whatever. "enum" does something similar, but to structures
(value-types, which are also classes, types and objects - whatever :),
etc.

'Twas merely a rhetorical question Dave. I know that you know that I'm comfortable
with value types (and vice versa). :-D

>While all types are .NET classes that descend from System.Object
(excepting System.Object itself) is completely true on the
metadata-level, the CLR does not treat all types the same and it is
important to make distinctions between value types and reference
types. Because if you don't, the simply confuse the novice C#
developer later.

I agree that the distinction is important, but I think it's the
distinction itself that commonly confuses novice developers regardless
of whether it becomes apparent sooner or later in their exploration of
C#. Though, I think that making these distinctions later allows
novices to focus on syntax and grammar, which should definitely come
first, IMO. As soon as they ask, "What's a struct?", as you put it,
or, "Where did the value of this variable go?", that's when a
conversation such as this should take place :)

Truely stated. I guess that the point that I want to make is that, the blanket
statement that "all types are classes and all classes are types" is going
to be more confusing than helpful to a novice C# developer because it mixes
metaphors a bit between the framework and the language. A better approach
might be to simply say (as Jeffrey Richter does), "all types are derived
from System.Object". That is a clear statement about a truth in the .NET
framework and won't be confused with the semantics of the C# language. In
fact, understanding that truth is necessary before any of the other details
about types (e.g. boxing, reference vs. value types, object equality and
identity, etc.).

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Dustin,

Agreed.

And as for the rhetoric, I got it - I just wanted to submit what I felt an
appropriate answer would be ;)

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>>>ALL types are classes. And all classes are types.

However, that statement simply confuses C# developers because the
next questions are often: "so what's a struct? Is that a class too?
Then, why don't I declare it with the 'class' keyword?"

ValueType adds additional semantics to classes. Using "struct"
instead of "class" tells the C# compiler that you would like to use
those additional semantics (and behavior) in your class, type, object
- whatever. "enum" does something similar, but to structures
(value-types, which are also classes, types and objects - whatever :),
etc.

'Twas merely a rhetorical question Dave. I know that you know that I'm
comfortable with value types (and vice versa). :-D

>>While all types are .NET classes that descend from System.Object
(excepting System.Object itself) is completely true on the
metadata-level, the CLR does not treat all types the same and it is
important to make distinctions between value types and reference
types. Because if you don't, the simply confuse the novice C#
developer later.

I agree that the distinction is important, but I think it's the
distinction itself that commonly confuses novice developers regardless
of whether it becomes apparent sooner or later in their exploration of
C#. Though, I think that making these distinctions later allows
novices to focus on syntax and grammar, which should definitely come
first, IMO. As soon as they ask, "What's a struct?", as you put it,
or, "Where did the value of this variable go?", that's when a
conversation such as this should take place :)

Truely stated. I guess that the point that I want to make is that, the
blanket statement that "all types are classes and all classes are types"
is going to be more confusing than helpful to a novice C# developer
because it mixes metaphors a bit between the framework and the language. A
better approach might be to simply say (as Jeffrey Richter does), "all
types are derived from System.Object". That is a clear statement about a
truth in the .NET framework and won't be confused with the semantics of
the C# language. In fact, understanding that truth is necessary before any
of the other details about types (e.g. boxing, reference vs. value types,
object equality and identity, etc.).

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dustin Campbell]

Agreed.

>
And as for the rhetoric, I got it - I just wanted to submit what I
felt an appropriate answer would be ;)

Oh good. I'm glad that we agree. Because when we don't agree, it usually
turns into some long thread that nobody can follow. ;-)

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Dustin,

>Agreed.

And as for the rhetoric, I got it - I just wanted to submit what I
felt an appropriate answer would be ;)

Oh good. I'm glad that we agree. Because when we don't agree, it usually
turns into some long thread that nobody can follow. ;-)

Ha. I don't really care though as long as we can follow it, although that's
probably not always the case either ;)

--
Dave Sexton

[Jon Skeet [C# MVP]]

Kevin Spencer <sp**@uce.govwrote:

So-called "Native Types" (int, double, struct, enum, etc) ARE classes,
which inherit System.ValueType, which inherits System.Object. See:

That depends (partly) on whether you're using CLI terminology or C#
terminology.

In C# terms, structs, enums etc are *not* classes. From instance, from
section 8.2 of the C# ECMA spec:

<quote>
C# supports two kinds of types: value types and reference types. Value
types include simple types (e.g., char, int, and float), enum types,
and struct types. Reference types include class types, interface types,
delegate types, and array types.
</quote>
In CLI terms, things get more complicated, but various bits of the CLI
spec are at least suggestive of the idea that not everything *is* a
class:

(Section 1, Scope)
<quote>
A companion file, CLILibrary.xml, considered to be part of
this Partition, but distributed in XML format, provides details of each
class, value type, and interface in
the CLI Libraries.
</quote>

(Section 8, Common Type System)
<quote>
Simplicity: in particular, variance is only permitted on generic
interfaces and generic delegates (not classes or value-types)
</quote>

Unfortunately I can't find a clear definition for "class" in the CLI
spec.

Note that value types themselves do *not* inherit from System.ValueType
- their boxed equivalents do. The fact that they *appear* to when using
them is cunning magic (or at least, more detail than I'm willing to
include here). The tree shown by MSDN is showing that relationship.

To be absolutely clear, quoting from the CLI spec section 8.9.10, Value
Type Inheritance:

<quote>
In their unboxed form value types do not inherit from any type. Boxed
value types shall inherit directly from System.ValueType unless they
are enumerations, in which case, they shall inherit from System.Enum.
Boxed value types shall be sealed.
</quote>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Gary... There are many definitions for the word type. In C# I find the
definition of
a type as a named generic interface to be a useful definition. In a
nutshell a
general interface is a particular set of signatures. A type is a named
interface. So
by this definition an object can have many named general interfaces. For
instance, a class may implement zero of more C# interfaces and each of
these
interfaces is a type. Morover, a class may be part of an inheritance
hierarchy and
each class in the hierarchy is a named general interface and hence a
type. An
instance of a class, an object, always has at least one named general
interface,
its class, and hence an object always has class. A reference variable
has a named
interface and hence a reference variable has a type. A delegate defines
a very
limited general interface, but by this definition a delegate still
defines a type.

If this definition of a type is not useful to you, then you are free to
ignore it.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Jeff Louie wrote:

Gary... There are many definitions for the word type. In C# I find the
definition of a type as a named generic interface to be a useful definition. In a
nutshell a general interface is a particular set of signatures.

It strikes me as a less than useful definition when "interface" and
"generic" are already defined in C#. A definition which not only needs
more definitions in order to be useful, but those definitions are
overloads of *existing* definitions is likely to lead to confusion, I
suspect.

(I know you said to ignore the definition if it's not helpful, but I
thought it was worth pointing out how potentially confusing it is.)

Jon

[Dustin Campbell]

Jeff Louie wrote:

>

>Gary... There are many definitions for the word type. In C# I find
the
definition of a type as a named generic interface to be a useful
definition. In a
nutshell a general interface is a particular set of signatures.

It strikes me as a less than useful definition when "interface" and
"generic" are already defined in C#. A definition which not only needs
more definitions in order to be useful, but those definitions are
overloads of *existing* definitions is likely to lead to confusion, I
suspect.

Agreed.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@16g2000cwy.googlegro ups.com...

Jeff Louie wrote:

>Gary... There are many definitions for the word type. In C# I find the
definition of a type as a named generic interface to be a useful
definition. In a
nutshell a general interface is a particular set of signatures.

It strikes me as a less than useful definition when "interface" and
"generic" are already defined in C#. A definition which not only needs
more definitions in order to be useful, but those definitions are
overloads of *existing* definitions is likely to lead to confusion, I
suspect.

Actually, I found the definition rather compelling. Programmers use
"generic" and "interface" all the time without referring to C# features, and
have done for years. Saying we shouldn't use them in defining terms like
"type" is like saying we shouldn't use the term "is" because it has a
specific meaning in C#. :)

///ark

[Jeff Louie]

Hi John... Point taken, but the definition that I have posted _pre
dates_ C#. More importantly it appears to be a definition used by
Microsoft in their documentation of delegates. Normally I just say
interface for gang of four interface and use key word coloring when I
use C# interface.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Dave Sexton]

Hi Mark,

However, the term "is" has the same semantics everywhere.

--
Dave Sexton

"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@16g2000cwy.googlegro ups.com...

>Jeff Louie wrote:

>>Gary... There are many definitions for the word type. In C# I find the
definition of a type as a named generic interface to be a useful
definition. In a
nutshell a general interface is a particular set of signatures.

It strikes me as a less than useful definition when "interface" and
"generic" are already defined in C#. A definition which not only needs
more definitions in order to be useful, but those definitions are
overloads of *existing* definitions is likely to lead to confusion, I
suspect.

Actually, I found the definition rather compelling. Programmers use
"generic" and "interface" all the time without referring to C# features,
and have done for years. Saying we shouldn't use them in defining terms
like "type" is like saying we shouldn't use the term "is" because it has a
specific meaning in C#. :)

///ark

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

It strikes me as a less than useful definition when "interface" and
"generic" are already defined in C#. A definition which not only needs
more definitions in order to be useful, but those definitions are
overloads of *existing* definitions is likely to lead to confusion, I
suspect.

Actually, I found the definition rather compelling. Programmers use
"generic" and "interface" all the time without referring to C# features, and
have done for years.

And that's fine - but within a C# context, when talking about the type
system, it makes to only use C# terms for their C# meaning. By all
means use the word "contract" and explain that, but to use "interface"
for anything other than a C# interface seems counterproductive when
talking about C# types.

Saying we shouldn't use them in defining terms like
"type" is like saying we shouldn't use the term "is" because it has a
specific meaning in C#. :)

And if someone were trying to define the C# "as" operator in terms
using "is" but redefining the word "as" to mean something else, I'd
have problems with that too!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jeff Louie <an*******@devdex.comwrote:

Hi John... Point taken, but the definition that I have posted _pre
dates_ C#. More importantly it appears to be a definition used by
Microsoft in their documentation of delegates. Normally I just say
interface for gang of four interface and use key word coloring when I
use C# interface.

I think that would be fine if you were talking about type systems in
general, but when we're talking about the C# type system, it makes
sense to avoid terms which have a specific meaning in C#.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

Hi Mark,

However, the term "is" has the same semantics everywhere.

Depends what the meaning of "is" is.

///ark

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

And that's fine - but within a C# context, when talking about the type
system, it makes to only use C# terms for their C# meaning.

I agree - if to do otherwise would be confusing. I didn't find that
definition confusing (and I'm sure you didn't either).

And if someone were trying to define the C# "as" operator in terms
using "is" but redefining the word "as" to mean something else, I'd
have problems with that too!

I'm don't see how that applies. We're not talking about defining "interface"
any more than this sentence is talking about defining "defining." We're
using an implied (and obvious, IMO) meaning of "interface" to define a C#
concept. Again, I think it would be bad if that usage lead to confusion, but
it doesn't seem to.

///ark

[Dustin Campbell]

I'm don't see how that applies. We're not talking about defining

"interface" any more than this sentence is talking about defining
"defining." We're using an implied (and obvious, IMO) meaning of
"interface" to define a C# concept. Again, I think it would be bad if
that usage lead to confusion, but it doesn't seem to.

I just spoke to a user group on the topic of C# generics and had to back
up when I saw confusion across some faces due to my use of the term "generic
interface" in a way that wasn't referring to a C# interface that defines
generic type parameters. So, I'm not sure it's all that obvious. Context
is extremely important and, yes, it can lead to confusion.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

And that's fine - but within a C# context, when talking about the type
system, it makes to only use C# terms for their C# meaning.

I agree - if to do otherwise would be confusing. I didn't find that
definition confusing (and I'm sure you didn't either).

No, but then I'm not the target audience, as I already understand the
type system. We'd have to ask the OP whether it helped or not - and
even the OP may not know, as he may think he understands when he
doesn't, or vice versa.

And if someone were trying to define the C# "as" operator in terms
using "is" but redefining the word "as" to mean something else, I'd
have problems with that too!

I'm don't see how that applies. We're not talking about defining "interface"
any more than this sentence is talking about defining "defining." We're
using an implied (and obvious, IMO) meaning of "interface" to define a C#
concept.

It wasn't implied - it was stated:

<quote>
In a nutshell a general interface is a particular set of signatures.
</quote>

Now that would be fine in itself, but then when someone starts learning
about C# interfaces, how do they talk about the difference between
classes and interfaces, if they've learned about classes in terms of
interfaces meaning something different?

Overloading terms just seems like a bad idea to me. The fact that
Jeff's post had to differentiate several times between "general
interfaces" (having used the term "generic interfaces" earlier, btw)
and "C# interfaces" rings warning bells to start with. Whenever you
have to add a modifier to every occurrence of a word to make its
meaning clear, it's worth thinking about whether a different word
wouldn't make things easier to start with. Sometimes that doesn't work,
when the term is overloaded within the specific domain we're talking
about (my article about delegates has just this problem, for instance -
but I think it's unavoidable there), but when there are alternatives, I
think it's a good idea to use them.

For example, suppose Jeff had used the word "contract" instead of
"interface" when talking about "general interfaces". He could have
specified what he meant by "contract" just as easily as he did "general
interface" and it wouldn't have interfered with the C# meaning of the
word "interface" at all.

Again, I think it would be bad if that usage lead to confusion, but
it doesn't seem to.

I don't think we can know that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jeff Louie]

John... what is funny is that I used the word contract many years ago to
describe a C# interface and now I hear back at me :) I think that you
have a good idea at how I can make this idea less confusing, _but_ it
would be at the sad loss of the history of the gang of four definition
of type which most definitely uses the word interface. I will think on
this.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[garyusenet]

This thread has been more help than any can imagine. I really am
indebted to all of you for sharing your insights into this.

As a (very useful) excercise I have spent the last couple of hours
reading over the thread trying to get a grasp on the different aspects
that have been raised. In summary am I correct to say the following: -

A Class is a mechanism for creating a new type.

Native types are defined by the clr, and for that reason do not require
the programmer to define them by creating new classes. All native types
are classes. All of them, be they reference or value type are derived
from the ultimate base class Object.

The different user defined types available in C# are:
Class, Interface, Struct,Enum,Delegate.

When a variable is Instantiated it becomes a bit of memory.
This bit of memory either stores a label (for value types)
or a pointer (which is a memory address) for reference types.

Questions: -

Q.1.
Kevin made the distinction that All MANAGED types are classes.
What does managed/unmanaged mean in this respect?
and does this mean that UNMANAGED types are not classes. What is an
example of an unmanaged type? What implications does such a type not
being a class, have?

Q.2.
When I look at a class from now on I will look at it as ultimately
defining a user type, is this correct?

Q.3.
In order for a class to 'define' a type, it must say something about
this type, what does a class say about the type that it defines, and
how does it say it?

Q.4.
All classes are types. I do not understand this.

A type of variable indicates the data the variable can store, and the
operations that can be performed on that variable.

But if i create a class which simply has an empty main method, how can
this be called a type? in what way is it defining data, or operations
that can be performed on data?

I hope my naivity on this matter isn't too annoying for you. This seems
so easy to most of you, it must be quite painful to witness my lack of
grasp of these points!

Many Many Thanks,

Gary-

[Mark Wilden]

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>
I just spoke to a user group on the topic of C# generics and had to back
up when I saw confusion across some faces due to my use of the term
"generic interface" in a way that wasn't referring to a C# interface that
defines generic type parameters. So, I'm not sure it's all that obvious.
Context is extremely important and, yes, it can lead to confusion.

It's context that lets us use the same word for different concepts. In the
context of the definition provided, I don't believe the use of the terms
"interface" and "generic" was confusing. In other contexts (which include
audience), it may be.

///ark

[Dustin Campbell]

>I just spoke to a user group on the topic of C# generics and had to

>back up when I saw confusion across some faces due to my use of the
term "generic interface" in a way that wasn't referring to a C#
interface that defines generic type parameters. So, I'm not sure it's
all that obvious. Context is extremely important and, yes, it can
lead to confusion.

It's context that lets us use the same word for different concepts. In
the context of the definition provided, I don't believe the use of the
terms "interface" and "generic" was confusing. In other contexts
(which include audience), it may be.

Which is why (as Jon has pointed out) it's dangerous terminology and other
words should probably be chosen. In this newsgroup, we *are* in the context
of an audience after all. Therefore, it's a confusing definition to post.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Mark Wilden <mw*****@communitymtm.comwrote:

And that's fine - but within a C# context, when talking about the type
system, it makes to only use C# terms for their C# meaning.

I agree - if to do otherwise would be confusing. I didn't find that
definition confusing (and I'm sure you didn't either).

No, but then I'm not the target audience, as I already understand the
type system. We'd have to ask the OP whether it helped or not - and
even the OP may not know, as he may think he understands when he
doesn't, or vice versa.

You know, I see a lot remarks like this that assume the real problem with a
concept or explanation is not that it's confusing to the speaker, or even to
anyone else in the conversation, but that it's bad because it just might
confuse some hypothetical idiot. This same line of thinking is used to
deprecate features like multiple inheritance. It's not that -we- would have
any problem using it - no, sir - but we feel for the poor newbies who will
screw it up.

>I'm don't see how that applies. We're not talking about defining
"interface"
any more than this sentence is talking about defining "defining." We're
using an implied (and obvious, IMO) meaning of "interface" to define a C#
concept.

It wasn't implied - it was stated:

<quote>
In a nutshell a general interface is a particular set of signatures.
</quote>

You're right - my mistake.

Now that would be fine in itself, but then when someone starts learning
about C# interfaces, how do they talk about the difference between
classes and interfaces, if they've learned about classes in terms of
interfaces meaning something different?

I think the term "interface" has a much broader meaning that every
programmer must understand.

Overloading terms just seems like a bad idea to me.

It may be bad in one instance or another, but it can't be bad in general,
since our whole language is based on it.

but when there are alternatives, I think it's a good idea to use them.

The thing is that, unless you're an Eiffel programmer, you'll generally hear
"interface" (the non-C# usage, which is many years older than the C# usage)
defined in terms of "contract." "Contract" is way more overloaded than
"interface"!

For example, suppose Jeff had used the word "contract" instead of
"interface" when talking about "general interfaces". He could have
specified what he meant by "contract" just as easily as he did "general
interface" and it wouldn't have interfered with the C# meaning of the
word "interface" at all.

However, I admit that I don't think that would be a bad idea.

>Again, I think it would be bad if that usage lead to confusion, but
it doesn't seem to.

I don't think we can know that.

Yes, we can know whether or not there -seems- to have been confusion. There
doesn't. That doesn't mean none exists, but there's no evidence that it
does.

[Dustin Campbell]

Gary,

I'm recommending an excellent book out there by Jeffrey Richter call "CLR
via C#". You're certainly welcome to ask questions here (especially since
some of them have spawned enjoyable debate) but you will probably find the
explanations in this book to be fantastically clear. There are entire chapters
devoted to what .NET types are.

http://www.amazon.com/CLR-via-Second...e=UTF8&s=books

Best Regards,
Dustin Campbell
Developer Express Inc.

[Mark Wilden]

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...

>
Which is why (as Jon has pointed out) it's dangerous terminology and other
words should probably be chosen. In this newsgroup, we *are* in the
context of an audience after all. Therefore, it's a confusing definition
to post.

Were you confused?

///ark

[Dustin Campbell]

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in

message news:c1**************************@news.microsoft.c om...

>Which is why (as Jon has pointed out) it's dangerous terminology and
other words should probably be chosen. In this newsgroup, we *are* in
the context of an audience after all. Therefore, it's a confusing
definition to post.

Were you confused?

I fail to see how that is relevent.

Best Regards,
Dustin Campbell
Developer Express Inc.

[Dave Sexton]

Hi Mark,

"is" is the 3rd person present singular of "be". This is true even in C# :)

http://dictionary.reference.com/browse/is

Anyway, even if there was any ambiguity in "is" it wouldn't really prove
your original argument at all. The fact remains that "contract", as Jon
pointed out, is not an overloaded term in C#, and is therefore more
appropriate. "Interface" and "generic" are overloaded terms and are
therefore less appropriate.

As far as your education is concerned, this thread might as well not exist
since you probably already understand the topic. For those that find the
information to be valuable and may actually learn something, it's better to
be accurate and clear.

--
Dave Sexton

"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:Oi**************@TK2MSFTNGP02.phx.gbl...

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

>Hi Mark,

However, the term "is" has the same semantics everywhere.

Depends what the meaning of "is" is.

///ark

[Jon Skeet [C# MVP]]

<ga********@myway.comwrote:

This thread has been more help than any can imagine. I really am
indebted to all of you for sharing your insights into this.

As a (very useful) excercise I have spent the last couple of hours
reading over the thread trying to get a grasp on the different aspects
that have been raised. In summary am I correct to say the following: -

A Class is a mechanism for creating a new type.

Well, it's more that a class *is* a type.

Native types are defined by the clr, and for that reason do not require
the programmer to define them by creating new classes. All native types
are classes. All of them, be they reference or value type are derived
from the ultimate base class Object.

I dispute Kevin's claim about all managed types being classes, so I'm
afraid there'll be some disagreement there.

Also note that System.String is a type which is defined in the CLI spec
(IIRC).

The question of inheritance and value types is a slightly tricky one,
and I seem to remember that the C# spec and the CLI spec approach the
matter using different terminology. (In particular, I'm pretty sure
that the CLI spec treats "derives from" and "inherits from" as subtly
different concepts, even though the two are used interchangably in most
conversations.)

The different user defined types available in C# are:
Class, Interface, Struct,Enum,Delegate.

I don't think it's worth making the "user-defined" distinction there.

When a variable is Instantiated it becomes a bit of memory.

The variable doesn't "become" a bit of memory. A variable has a name
and a value. Depending on the variable, it may be

This bit of memory either stores a label (for value types)
or a pointer (which is a memory address) for reference types.

Not sure what you mean by "label" here.

Questions: -

Q.1.
Kevin made the distinction that All MANAGED types are classes.
What does managed/unmanaged mean in this respect?
and does this mean that UNMANAGED types are not classes. What is an
example of an unmanaged type? What implications does such a type not
being a class, have?

As I said before, I disagree with Kevin in terms of whether value types
are classes or not, so I'm not sure I can really speak to this one.

Q.2.
When I look at a class from now on I will look at it as ultimately
defining a user type, is this correct?

Depends what you mean by "user type" and "look at". There are plenty of
classes defined by the framework and not by "users" as such.

Q.3.
In order for a class to 'define' a type, it must say something about
this type, what does a class say about the type that it defines, and
how does it say it?

It describes any or all of:
methods, variables, events, properties, constructors,
static constructor, finalizer, nested types

(There's probably something else I've missed off, but that's basically
it.)

Q.4.
All classes are types. I do not understand this.

Any class is a type, as is any struct.

A type of variable indicates the data the variable can store, and the
operations that can be performed on that variable.

Yes.

But if i create a class which simply has an empty main method, how can
this be called a type? in what way is it defining data, or operations
that can be performed on data?

If the class just has a static Main method, you could still call
ToString, GetHashCode etc on it, even though they wouldn't give you any
useful information. It wouldn't be defining any extra data or
operations which could be called on instances of the type - but almost
all classes do.

I hope my naivity on this matter isn't too annoying for you. This seems
so easy to most of you, it must be quite painful to witness my lack of
grasp of these points!

It's not painful, but I still think that books are a better way of
getting a handle on this kind of topic.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

No, but then I'm not the target audience, as I already understand the
type system. We'd have to ask the OP whether it helped or not - and
even the OP may not know, as he may think he understands when he
doesn't, or vice versa.

You know, I see a lot remarks like this that assume the real problem with a
concept or explanation is not that it's confusing to the speaker, or even to
anyone else in the conversation, but that it's bad because it just might
confuse some hypothetical idiot. This same line of thinking is used to
deprecate features like multiple inheritance. It's not that -we- would have
any problem using it - no, sir - but we feel for the poor newbies who will
screw it up.

I have no problem in saying that I'd probably screw up using multiple
inheritance :)

I fail to see what's controversial about the idea that a statement that
is understandable to those who already know the subject matter could be
confusing to those who are new to the topic though.

As an example, if I were to use the word "reference" in two different
ways in the same sentence (talking about "pass by reference" semantics
and "reference types") I would expect people who understood parameter
passing and the type system to understand what I meant, but I *know*
this causes confusion for a lot of people.

<snip>

Now that would be fine in itself, but then when someone starts learning
about C# interfaces, how do they talk about the difference between
classes and interfaces, if they've learned about classes in terms of
interfaces meaning something different?

I think the term "interface" has a much broader meaning that every
programmer must understand.

Yes, but in the discussion of C# types it's almost always used to mean
the C# interface, and overloading it there seems like a bad idea to me.

Overloading terms just seems like a bad idea to me.

It may be bad in one instance or another, but it can't be bad in general,
since our whole language is based on it.

It causes confusion when multiple meanings are available within the
same context, both in computing and in "normal" conversations. Heck, if
that weren't the case, a lot of sit-coms would far fewer jokes!

but when there are alternatives, I think it's a good idea to use them.

The thing is that, unless you're an Eiffel programmer, you'll generally hear
"interface" (the non-C# usage, which is many years older than the C# usage)
defined in terms of "contract." "Contract" is way more overloaded than
"interface"!

But not within the context of the C# type system, as C# doesn't define
the term "contract" anywhere. That's the important point, IMO.

For example, suppose Jeff had used the word "contract" instead of
"interface" when talking about "general interfaces". He could have
specified what he meant by "contract" just as easily as he did "general
interface" and it wouldn't have interfered with the C# meaning of the
word "interface" at all.

However, I admit that I don't think that would be a bad idea.

Again, I think it would be bad if that usage lead to confusion, but
it doesn't seem to.

I don't think we can know that.

Yes, we can know whether or not there -seems- to have been confusion. There
doesn't. That doesn't mean none exists, but there's no evidence that it
does.

I can't see there's any evidence either way. It's like me saying that
you don't seem to have any knowledge of music - I have no evidence
either way, so you *could* argue that it's a valid statement. It paints
a different picture to the reality, however, which is just that I don't
have any clue about how much you know about music.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Dustin Campbell]

I dispute Kevin's claim about all managed types being classes, so I'm

afraid there'll be some disagreement there.

As much as I disputed with him I have to agree that he is correct from the
standpoint of the CLR and the .NET framework. At the metadata-level, everything
really is a class. Believe me, I spend a great deal of time dealing with
the bits in the metadata tables themselves. However, the C# notion of a class
is really akin to CLR reference types. So, his assertions, while true, weren't
really appropriate to this thread. They just added confusion where none further
was needed. :-)

Best Regards,
Dustin Campbell
Developer Express Inc.

[Jon Skeet [C# MVP]]

Dustin Campbell <du*****@no-spam-pleasedevexpress.comwrote:

I dispute Kevin's claim about all managed types being classes, so I'm
afraid there'll be some disagreement there.

As much as I disputed with him I have to agree that he is correct from the
standpoint of the CLR and the .NET framework. At the metadata-level, everything
really is a class. Believe me, I spend a great deal of time dealing with
the bits in the metadata tables themselves. However, the C# notion of a class
is really akin to CLR reference types. So, his assertions, while true, weren't
really appropriate to this thread. They just added confusion where none further
was needed. :-)

Hmm... did you see my other post responding to Kevin's? Perhaps it's
just that the CLI spec is tragically poorly written in this respect,
but I see very little way of interpreting statements such as:

<quote>
Simplicity: in particular, variance is only permitted on generic
interfaces and generic delegates (not classes or value-types)
</quote>

other than to consider value types not to be classes. (It also suggests
that generic interfaces and generic delegates aren't classes, which
contradicts Kevin's statement unless you view generic
interfaces/delegates as not being types.)

I have a vague recollection of you posting some convincing evidence on
this front before, but couldn't find it recently - do you have any
quotes from the spec which would help?

My guess is that the spec is just contradictory, unfortunately.

I can see that a value type is declared using .class in IL, but that's
not quite the same thing as the concept of a class.

Indeed, looking at partition II's section 10, "Defining types" it
starts with:

<quote>
Types (i.e., classes, value types, and interfaces) can be defined at
the top-level of a module
</quote>

Again, doesn't that sound odd if value types and interfaces *are*
classes? Can you imagine the furore which would occur if someone
described a city has containing: "People (humans, women, and
Christians)"?
For further evidence, look at Partition II's table of contents which
contains sections: "Semantics of classes", "Semantics of interfaces",
"Semantics of value types" and "Semantics of special types". That,
again, suggests that value types aren't classes.

Similarly, in 13.3:
<quote>
Like classes, value types can have both instance constructors (§10.5.1)
and type initializers (§10.5.3). Unlike classes, whose fields are
automatically initialized to null, the following rules constitute the
only guarantee about the initilization of (unboxed) value types:
</quote>

If a value type *is* a class, how can "Unlike classes..." make sense?
My suspicion is that ".class" was a badly chosen name, but that it
*doesn't* always define a class.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:ut**************@TK2MSFTNGP05.phx.gbl...

Hi Mark,

"is" is the 3rd person present singular of "be". This is true even in C#
:)

http://dictionary.reference.com/browse/is

In C#, "is" is an operator, not a verb.

///ark