Is Class Synonymous with Type?

[garyu...@myway.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-

[Brian Gideon]

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

<garyu...@myway.com> wrote in message
news:1165327413.8...@16g2000cwy.googlegroups.com...

[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

[garyu...@myway.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

[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.
<garyu...@myway.com> wrote in message
news:1165330225....@f1g2000cwa.googlegroups.com...

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

[garyu...@myway.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-

[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/library/aa904377(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" <dus...@no-spam-pleasedevexpress.com> wrote in message
news:c155cb0e19e1c8...@news.microsoft.com...

[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/library/aa904377(VS.71).aspx
http://msdn2.microsoft.com/en-gb/library/system.valuetype(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" <pbra...@uwic.ac.uk> wrote in message
news:uECvC9HG...@TK2MSFTNGP04.phx.gbl...

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

[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

<garyu...@myway.com> wrote in message
news:1165334433.3...@j72g2000cwa.googlegroups.com...

[Peter Bradley]

Nice one. Thanks

Peter

"Kevin Spencer" <sp...@uce.gov> wrote in message
news:O%23DPngIG...@TK2MSFTNGP02.phx.gbl...

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

[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.).

[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" <dus...@no-spam-pleasedevexpress.com> wrote in message

news:c155cb0e19f128...@news.microsoft.com...

[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. ;-)

[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.gov> wrote:
> 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.

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message
news:1165394433.2...@16g2000cwy.googlegroups.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.

[Dave Sexton]

Hi Mark,

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

--
Dave Sexton

"Mark Wilden" <mwi...@communitymtm.com> wrote in message
news:%23O0p9MW...@TK2MSFTNGP05.phx.gbl...

[Jon Skeet [C# MVP]]

Mark Wilden <mwi...@communitymtm.com> wrote:
> > 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 [C# MVP]]

Jeff Louie <anon...@devdex.com> wrote:
> 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]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:%23N6SabW...@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.com> wrote in message

news:MPG.1fe129a74...@msnews.microsoft.com...

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

[Jon Skeet [C# MVP]]

Mark Wilden <mwi...@communitymtm.com> wrote:
> > 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.

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

[garyu...@myway.com]

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" <dus...@no-spam-pleasedevexpress.com> wrote in message

news:c155cb0e1a10f8...@news.microsoft.com...

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

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message

news:MPG.1fe137a3d...@msnews.microsoft.com...

> Mark Wilden <mwi...@communitymtm.com> wrote:
>> > 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-Jeffrey-Richter/dp/0735621632/sr=8-1/qid=1165446270/ref=pd_bbs_sr_1/104-0992090-2716705?ie=UTF8&s=books

[Mark Wilden]

"Dustin Campbell" <dus...@no-spam-pleasedevexpress.com> wrote in message

news:c155cb0e1a1348...@news.microsoft.com...

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

I fail to see how that is relevent.

[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" <mwi...@communitymtm.com> wrote in message

news:OiFkgJXG...@TK2MSFTNGP02.phx.gbl...

[Jon Skeet [C# MVP]]

<garyu...@myway.com> wrote:
> 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 [C# MVP]]

Mark Wilden <mwi...@communitymtm.com> wrote:
> > 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.

[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. :-)

[Jon Skeet [C# MVP]]

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.

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:utdrT8YG...@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

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message

news:MPG.1fe1654ff...@msnews.microsoft.com...

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

I've used MI a buncha times. It's really not a big deal. I had problems with
it when I first used it. I also had problems understanding pointers.

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

Oh, I completely grant that any statement could be confusing to anyone. But
"could be" is different from "is."

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

I'd have to see an example.

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

I know it seems like a bad idea to you. I just don't know if anyone actually
has trouble understanding it. You understood it. Dustin understood it. I
understood it. No one that we know of doesn't understand it. So there's
actually no evidence that the definiton is hard to understand.

That said, it doesn't hurt to be absolutely clear. I was really just talking
to my "hypothetical idiot" point (which is admittedly a pet peeve of mine).

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

I do argue that that's a valid statement. It's completely, 100% true.

The example isn't pertinent here, though, since this newsgroup is about C#
(and explanations thereof), not music, and one's knowledge of C# is quite in
evidence here.

I do have evidence for my belief about the definition:

1) Based on my knowledge of and experience with programmers, I don't think
the definition would be confusing to most or even some of them.

2) No one has expressed confusion.

Hence, 3) It seems that the definition is not confusing.

Do I -know- that invisible pink hippos don't orbit Saturn? It just seems
pretty likely that they do not, based on reasoning enumerated above. Pace
Donald Rumsfeld, the absence of evidence -is- evidence (though not proof) of
absence.

///ark

[Dustin Campbell]

Jon,

I'm going to change my tune now and wisely stop arguing falsehoods. Truthfully,
when I see the phrase "all .NET types are classes", my gut instinct is to
go along with this. However, it really isn't true. The CLI has the notion
of a TypeDef and that is *not* synonymous with a class. A TypeDef can be
a Class, Interface or ValueType but not any combination of the three.

- A TypeDef is a "Class" when its Interface bit (0x00000020) of its TypeAttributes
flags is not set. And, it must ultimately derive from System.Object.
- A TypeDef is an "Interface" when its Interface bit is set. It doesn't inherit
from anything.
- A TypeDef is a "ValueType" when its Interface bit is not set and it ultimately
derives from System.Object.

In addition to TypeDefs there are TypeSpecs which describe other kinds of
types (e.g. pointers, arrays, closed generic types, etc.). Often, these reference
TypeDefs.

And finally, there are TypeRefs which are simply references to TypeDefs or
TypeSpecs that appear in other modules.

The CLI spec seems ties the notion of a "class" to a "reference type".

[Dustin Campbell]

>> 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.
>>
> I'd have to see an example.

Mark, I don't want to assume that you don't teach programming to other developers
but, as a trainer, I see this sort of confusion all the time. Developers
come from lots of different backgrounds at many different levels. And, it's
likely that a large percentage of this newsgroup's audience are C# learners
-- not experience C# developers. So, using the least confusing language as
possible is always a good idea here (though that's not always achieved by
yours truly).

[Mark Wilden]

"Dustin Campbell" <dus...@no-spam-pleasedevexpress.com> wrote in message

news:c155cb0e1a1698...@news.microsoft.com...

> Mark, I don't want to assume that you don't teach programming to other
> developers

That would not only be a valid assumption - it would be a true assumption as
well. :)

> but, as a trainer, I see this sort of confusion all the time.

The difficulty is in qualifying "sort of."

> So, using the least confusing language as possible is always a good idea
> here (though that's not always achieved by yours truly).

It's impossible to use the least confusing language possible. If it were,
every post would be terabytes long. At some point, you have to be able to
assume a certain background. And understanding how "interface" in general
and "interface" as a C# construct are not identical would, I feel, be part
of most programmers' backgrounds. Maybe not. But I'm sticking with it.

Anyway, we're both arguing based on the characteristics of people we don't
even know - the readers of one particular newsgroup message. Which is kinda
silly, but which characterizes a lot of the arguments I participate in. :)

///ark

[Dave Sexton]

Hi Mark,

<snip>

>>> 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.
>
> I do argue that that's a valid statement. It's completely, 100% true.
>
> The example isn't pertinent here, though, since this newsgroup is about C#
> (and explanations thereof), not music, and one's knowledge of C# is quite
> in evidence here.
>
> I do have evidence for my belief about the definition:
>
> 1) Based on my knowledge of and experience with programmers, I don't think
> the definition would be confusing to most or even some of them.
>
> 2) No one has expressed confusion.
>
> Hence, 3) It seems that the definition is not confusing.
>
> Do I -know- that invisible pink hippos don't orbit Saturn? It just seems
> pretty likely that they do not, based on reasoning enumerated above. Pace
> Donald Rumsfeld, the absence of evidence -is- evidence (though not proof)
> of absence.

There is no evidence of anybody's particular level of experience or
knowledge other than the very few people posting, and any assumptions you
make thereof is a priori, not empirical. I'm sure there are many more
people from all over the world reading this thread, with experience varying
in great degree, other than just the few that are participating in this
conversation. Everybody's needs should be catered to here seeing that it's
a public newsgroup, and that can't be done accurately and clearly using
loose terminology.

I hope that's clear enough :)

--
Dave Sexton

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:e3h4OuZG...@TK2MSFTNGP05.phx.gbl...

> There is no evidence of anybody's particular level of experience or
> knowledge other than the very few people posting

Exactly. There is no actual evidence that anyone was confused by the post.
Hence, any assumption that the post was confusing is a priori, not
empirical.

>, and any assumptions you make thereof is a priori, not empirical.

D'oh! :)

> Everybody's needs should be catered to here seeing that it's a public
> newsgroup

It is impossible to cater to everyone's needs.

> and that can't be done accurately and clearly using loose terminology.

What we're arguing about is the definition of "loose." A type theorist might
say that any definition that uses words instead of mathematical symbols is
"loose."

///ark

[Jon Skeet [C# MVP]]

Dustin Campbell <dus...@no-spam-pleasedevexpress.com> wrote:
> I'm going to change my tune now and wisely stop arguing falsehoods. Truthfully,
> when I see the phrase "all .NET types are classes", my gut instinct is to
> go along with this. However, it really isn't true. The CLI has the notion
> of a TypeDef and that is *not* synonymous with a class. A TypeDef can be
> a Class, Interface or ValueType but not any combination of the three.

<snip>

Cool. I can stop trying to work out where the spec contradicts itself
in that case :)

[Jon Skeet [C# MVP]]

Mark Wilden <mwi...@communitymtm.com> wrote:
> > I have no problem in saying that I'd probably screw up using multiple
> > inheritance :)
>
> I've used MI a buncha times. It's really not a big deal. I had problems with
> it when I first used it. I also had problems understanding pointers.

Unfortunately I'm finding it hard to

> > 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.
>
> Oh, I completely grant that any statement could be confusing to anyone. But
> "could be" is different from "is."

Good job I originally talked about it being "potentially confusing" and
it being "likely to lead to confusion" then :)

> > 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.
>
> I'd have to see an example.

"When a reference type value is passed by value, it is the reference
which is passed, not the object; it is still passed by value (by
default) rather than by reference, but you need to be clear that the
value in question is a reference."

I often find myself making statements *like* that (hopefully a bit
clearer) because people associate "reference type" and "pass by
reference" when they shouldn't - and I believe that's largely *because*
the word "reference" appears in both.

> > 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.
>
> I know it seems like a bad idea to you. I just don't know if anyone actually
> has trouble understanding it. You understood it. Dustin understood it. I
> understood it. No one that we know of doesn't understand it. So there's
> actually no evidence that the definiton is hard to understand.

No, but I think it's

> That said, it doesn't hurt to be absolutely clear. I was really just talking
> to my "hypothetical idiot" point (which is admittedly a pet peeve of mine).

I think the difference is that I'm considering a hypothetical newbie,
not a hypothetical idiot. Were you an idiot when you didn't understand
pointers? No - just new to the idea.

In this case, we don't even need to look for a hypothetical newbie -
the post was a response to a *real* newbie (garyusenet) who has never
hidden his "newbieness". What we *don't* know is whether he found it
confusing, or whether he would have found it confusing if there hadn't
been all the other posts talking about types, or whether it may have
laid the foundations for confusion when he learns about interfaces.

> > 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.
>
> I do argue that that's a valid statement. It's completely, 100% true.
>
> The example isn't pertinent here, though, since this newsgroup is about C#
> (and explanations thereof), not music, and one's knowledge of C# is quite in
> evidence here.

And in this case, the OP's "newbieness" is in evidence too.

> I do have evidence for my belief about the definition:
>
> 1) Based on my knowledge of and experience with programmers, I don't think
> the definition would be confusing to most or even some of them.

Programmers with how much experience though? Having had to try various
ways of explaining certain concepts in the past, I believe a C# newbie
could very easily be confused by the different uses of "interface" in
the statement, either when they first hear it or later when they then
start to use C# interfaces.

> 2) No one has expressed confusion.
>
> Hence, 3) It seems that the definition is not confusing.

I disagree with the logic there, because it's so easy for it to have
confused someone a) without them knowing or b) without them wanting to
display that ignorance.

> Do I -know- that invisible pink hippos don't orbit Saturn? It just seems
> pretty likely that they do not, based on reasoning enumerated above.

Given that I disagree with you on point 1, it's unsurprising that I
disagree with the conclusion.

> Pace Donald Rumsfeld, the absence of evidence -is- evidence (though not proof) of
> absence.

It's evidence, but not particularly strong evidence - whereas I believe
that the evidence of common sense is that overloading terms
unnecessarily (within a context where there is a specified meaning of
those terms) leads to an unnecessarily high potential for confusion. In
this case, I think the potential is great, and you disagree, which is
fine.

I've seen enough people getting confused by relatively clear
descriptions of the type system to want to err on the side of caution.

[Dave Sexton]

Hi Mark,

>> There is no evidence of anybody's particular level of experience or
>> knowledge other than the very few people posting
>
> Exactly. There is no actual evidence that anyone was confused by the post.
> Hence, any assumption that the post was confusing is a priori, not
> empirical.

But you've only addressed half of my point. There is also no evidence that
it helped anyone, so you have no base for your claim.

I was suggesting that we can't know either way, with any degree of
certainty, unless we were to take a poll or something. Therefore, it's best
to be as clear as possible when posting since you never really no who will
be reading it.

As for any OP's level of expertise, what you assume as a respondent may set
the basis for the amount of detail in your reply, but any assumptions made
thereof should by no means allow a reduction in clarity in any form.

>>, and any assumptions you make thereof is a priori, not empirical.
>
> D'oh! :)

;)

>> Everybody's needs should be catered to here seeing that it's a public
>> newsgroup
>
> It is impossible to cater to everyone's needs.

It's not impossible to try.

>> and that can't be done accurately and clearly using loose terminology.
>
> What we're arguing about is the definition of "loose." A type theorist
> might say that any definition that uses words instead of mathematical
> symbols is "loose."

Our [discussion] isn't focused on the definition of "loose". It's quite
obvious to everyone, AFAICT, that the terms used in the original response
aren't C# terms that apply to the subject matter, and therefore can be
considered "loose" within a C# newsgroup.

Regardless, and what I think the actual [discussion] was about, is that you
don't think overloading terms is ambiguous, correct? (I ask regardless of
context, since the point of clarity is to reduce the amount of assumptions
that must be made in order to better understand the written material.)

--
Dave Sexton

[garyu...@myway.com]

Very interesting, one day I hope to be able to follow such scholarly
debate.

I'm going to see if I can find that book ' CLR via C# ' in the
bookshops at lunchtime (im in the UK) I haven't tried to find a
programming book in a bookshop before, so I don't know what my chances
of success will be.

If they do not have it in stock i'll order it from Google. But I want
to read it this evening!

You are all very kind,

Gary-

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk...@pobox.com> wrote in message

news:MPG.1fe19c7a9...@msnews.microsoft.com...

(I'm going to forgo responding to a lot of what you and Dave posted, as it
would only be repetitive.)

> I think the difference is that I'm considering a hypothetical newbie,
> not a hypothetical idiot. Were you an idiot when you didn't understand
> pointers? No - just new to the idea.

I think it would take an idiot not to understand the difference between an
interface in general terms vs. the C# keyword. Not a newbie - an idiot.

When I was a newbie to pointers and MI, I was not an idiot and I didn't do
idiotic things with them. It just took me some time to completely "grok" the
subjects.

BTW, a person who asks about the difference between a type and a class is
not a newbie in my book, nor an idiot. It's a subtle concept (as evidenced
by this very thread) that most newbies wouldn't even bother themselves with.

> I disagree with the logic there, because it's so easy for it to have
> confused someone a) without them knowing or b) without them wanting to
> display that ignorance.

I agree. However, the fact that no one has expressed confusion for those
reasons cannot be called -evidence- that the definition is confusing. The
fact is, there is no such evidence.

>> Do I -know- that invisible pink hippos don't orbit Saturn? It just seems
>> pretty likely that they do not, based on reasoning enumerated above.
>
> Given that I disagree with you on point 1, it's unsurprising that I
> disagree with the conclusion.

The hippo conclusion? :)

> the evidence of common sense

There's no such thing. Evidence refers to factual phenomena, not thinking
processes.

> I've seen enough people getting confused by relatively clear
> descriptions of the type system to want to err on the side of caution.

Yeah, it couldn't hurt.

///ark

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:uuL04qbG...@TK2MSFTNGP05.phx.gbl...

>>
>> Exactly. There is no actual evidence that anyone was confused by the
>> post. Hence, any assumption that the post was confusing is a priori, not
>> empirical.
>
> But you've only addressed half of my point.

Your point was that a priori statements were less valuable than those
supported by evidence (if I understood you). I was just pointing out that
your statement was even less supported by evidence than mine.

> There is also no evidence that it helped anyone, so you have no base for
> your claim.

1) I'm not claiming the definition helped anyone, so this statement isn't
relevant. 2) But in fact the definition did help me.

> I was suggesting that we can't know either way, with any degree of
> certainty

I'm not seeking certainty, and neither are you or Jon. Nor (just to
forestall a comment I can see coming) should we try.

>, unless we were to take a poll or something. Therefore, it's best to be
>as clear as possible when posting since you never really no who will be
>reading it.

As I said, it's literally impossible to be "as clear as possible."

> As for any OP's level of expertise, what you assume as a respondent may
> set the basis for the amount of detail in your reply, but any assumptions
> made thereof should by no means allow a reduction in clarity in any form.

This statement just has no meaning. "In any form"??

>> It is impossible to cater to everyone's needs.
>
> It's not impossible to try.

Then let's see you "try" to learn French or Russian, if you think it's so
important to cater to everybody. I mean, c'mon. :)

[Jon Skeet [C# MVP]]

Mark Wilden <mwi...@communitymtm.com> wrote:

<snip>

I'm not sure we're getting anywhere productive - I hope you don't mind
if I pull out of this part of the thread at this point.

[Dustin Campbell]

> Mark Wilden <mwi...@communitymtm.com> wrote:
>
> <snip>
>
> I'm not sure we're getting anywhere productive - I hope you don't mind
> if I pull out of this part of the thread at this point.

I pulled out awhile ago for the same reason. It has become argument for the
sake of argument.

[Mark Wilden]

"Dustin Campbell" <dus...@no-spam-pleasedevexpress.com> wrote in message

news:c155cb0e1a35d8...@news.microsoft.com...

>
> I pulled out awhile ago for the same reason. It has become argument for
> the sake of argument.

Actually, I was wondering what you guys were doing here in the first place.
It was a very silly argument. :)

///ark

[Dave Sexton]

Hi Mark,

Please stop removing large portions of my post when responding to them if
they are still appropriate, which I believe much of my last response was.
It causes the conversations to go in circles. Instead, leave the running
conversations so we can reference each others comments and so the flow of
the conversation is more obvious to readers.

I'll give it one more shot (I see our peers have given up ;)...

>>> Exactly. There is no actual evidence that anyone was confused by the
>>> post. Hence, any assumption that the post was confusing is a priori, not
>>> empirical.
>>
>> But you've only addressed half of my point.
>
> Your point was that a priori statements were less valuable than those
> supported by evidence (if I understood you).

No, my point wasn't a pseudo-definition of a priori. There is simply no
evidence either way, so I choose to "err on the side of caution" as well, to
quote Jon :)

> I was just pointing out that your statement was even less supported by
> evidence than mine.

But according to your logic, the "evidence" in support of your own
statements is actually the same as the "evidence" against you. In other
words, you think that since we have no proof that it wasn't clear to people
that we should just assume that it was (I've quoted you on this below).
Well, if it was absolutely clear to us then we wouldn't be in this
conversation to begin with. Obviously, it's not clear to us even though we
understood what the OP meant. You claim that it was clear to you. So,
according to your logic, the ratio is ~3-1 against you :)

>> There is also no evidence that it helped anyone, so you have no base for
>> your claim.
>
> 1) I'm not claiming the definition helped anyone, so this statement isn't
> relevant. 2) But in fact the definition did help me.

Mark: "Hence, 3) It seems that the definition is not confusing."

Therefore, it may have been helpful to others as it has helped you, but it
certainly wasn't confusing to anyone - that's what you're implying. If you
don't believe that, then there is absolutely no reason for this
conversation. My point was simple: you can have absolutely no idea who it
has confused or who it has helped except for yourself.

>> I was suggesting that we can't know either way, with any degree of
>> certainty
>
> I'm not seeking certainty, and neither are you or Jon. Nor (just to
> forestall a comment I can see coming) should we try.

Actually, I agree with you that we shouldn't try to be certain about whether
people are confused or not, and I don't see why you thought that I wouldn't
have agreed.

I think I've made it quite clear that my vote is for clarity (err on the
side of caution), not try to find out what some random sample of the
population expects from us as volunteers, in terms of clarity. I KNOW that
there are many people with varying levels of skill that read newsgroup
posts. I don't just assume that there is absolutely no confusion in any
given post, as you obviously do from some of your remarks in this thread,
one of which I've quoted above.

<snip>

>> As for any OP's level of expertise, what you assume as a respondent may
>> set the basis for the amount of detail in your reply, but any assumptions
>> made thereof should by no means allow a reduction in clarity in any form.
>
> This statement just has no meaning. "In any form"??

Yes, information comes in many different forms and clarity is part of them
all. There can be clarity (or lack thereof) in terminology, grammar, sample
code, format, etc.

I'm suggesting that any assumptions that you make about the OP's level of
expertise shouldn't have any affect on the level of clarity that you choose
in your posts, in any of the above forms that I've given as examples. I was
also suggesting that the LOD could vary slightly based on those same
assumptions.

>>> It is impossible to cater to everyone's needs.
>>
>> It's not impossible to try.
>
> Then let's see you "try" to learn French or Russian, if you think it's so
> important to cater to everybody. I mean, c'mon. :)

In an English speaking newsgroup?

You're just being ridiculous.

--
Dave Sexton

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:OXJ3tMlG...@TK2MSFTNGP05.phx.gbl...

> Hi Mark,
>
> Please stop removing large portions of my post when responding to them if
> they are still appropriate, which I believe much of my last response was.

We've been through this before, Dave. You're a "long quoter;" I'm not. Your
original words are easily available, and anyone who's followed the
conversation has already read them anyway. I only quote to provide reference
for what I'm about to say. There's no need to quote parts I don't reply to.

> Well, if it was absolutely clear to us then we wouldn't be in this
> conversation to begin with.

Nope - that's my whole, entire, complete point. :) The definition was clear
to us - but some of us are worried about what I've been calling
"hypothetical idiots."

> Obviously, it's not clear to us even though we understood what the OP
> meant.

You're introducing a new wrinkle - that even smart folks would have trouble
with the definition. I think you need to be more careful with your pronouns.

Sorry, I just don't have the energy to respond to more.

///ark

[Dave Sexton]

Hi Mark,

You still haven't addressed some of the concepts that I've tried to explain,
only particular sentences that have limited meaning on their own. You seem
to be perfectly content picking things out of context that you feel are
easily debated, but completely ignore relevant points.

I too would prefer to do more productive things with my time, so I'm going
to finish with this post as well. Thanks for the discussion.

--
Dave Sexton

"Mark Wilden" <mwi...@communitymtm.com> wrote in message

news:ugif7mlG...@TK2MSFTNGP03.phx.gbl...

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:uSIxhvlG...@TK2MSFTNGP06.phx.gbl...

>
> You still haven't addressed some of the concepts that I've tried to
> explain, only particular sentences that have limited meaning on their own.
> You seem to be perfectly content picking things out of context that you
> feel are easily debated, but completely ignore relevant points.

Obviously, I disagree. Furthermore, I'd appreciate if you would refrain from
personal remarks. This is the C# newsgroup and my level of contentment is
not on-list. K?

///ark

[Dave Sexton]

Hi Mark,

Sure, as long as you agree to discontinue making assumptions about things
I've written after pulling them out-of-context:

>> Obviously, it's not clear to us even though we understood what the OP
>> meant.
>
> You're introducing a new wrinkle - that even smart folks would have
> trouble with the definition. I think you need to be more careful with your
> pronouns.

--
Dave Sexton

"Mark Wilden" <mwi...@communitymtm.com> wrote in message

news:%23C5hR6l...@TK2MSFTNGP03.phx.gbl...

[Mark Wilden]

"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message

news:e6AMLEmG...@TK2MSFTNGP04.phx.gbl...

> Sure, as long as you agree to discontinue making assumptions about things
> I've written after pulling them out-of-context:

In the spirit of acquiescing to refraining from beating my wife, yes, I
hereby agree. :)

///ark