Is Class Synonymous with Type?

[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

 

[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,

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

 

[Jon Skeet [C# MVP]]

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>

 

[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

 

[Jon Skeet [C# MVP]]

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]

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]

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

 

[Dave Sexton]

Hi Mark,

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

 

[Jon Skeet [C# MVP]]

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 [C# MVP]]

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#.

 

[Mark Wilden]

Hi Mark,

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

Depends what the meaning of "is" is.

///ark

 

[Mark Wilden]

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]]

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.

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.

 

[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

 

[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]

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

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