3

This is probably a very simple question but I have a confusion about the Type definition.

When you want to provide a definition of the term Type such as Int, String or...
Immediately the word Template comes to mind, but its so close to the "Class" definition, now I want to know what is exactly the definition of The term Type.

Is it the same as class definition !? Type == class !?

If so, we know that there are other (reference)Types in c# that are not Class such as Interface and Delegate.

Is it correct to use Type and Class interchangeably?
Could you please give me a comprehensive definition about Type.
thanks in advance.

siamak
  • 669
  • 1
  • 10
  • 28
  • 3
    I was about to post my answer, saw the "1 answer has been posted since you loaded - load new answers" link show up, clicked it and noticed that the answer was from Jon Skeet. Then I gave up. – Tomas Aschan Jul 19 '11 at 09:53
  • i just wish that this question could be an answered question Not an unanswered one. – siamak Jul 19 '11 at 11:38

7 Answers7

14

As others have noted, the C# specification does not formally define "type". The C# spec does not attempt to be either a formal mathematical description of the language semantics or a tutorial for beginner programmers; you are expected to know what words like "type" and "value" and so on mean before you start reading the specification.

There are many possible definitions of "type", at varying levels of precision. For example, the ECMAScript specification somewhat informally defines a type as "a set of values", but since ECMAScript only has nine possible types, it does not need to have a strict, well-founded definition.

Another answer says that a type consists of a set of values, a set of rules for operating on those values, and a name. This is a very common working definition of a type, but it runs into problems when you try to think about it more formally. What is the name of an anonymous type? Is double*[][] the name of the type "jagged two dimensional array of pointers to double"? Does that type even have a name? Are List<int> and List<System.Int32> two different names for the same type? Does any set of values form a type? Are types themselves values? What is the type of a type? And so on. It's a good working definition but it doesn't quite hold up under scrutiny.

As a compiler writer, the way I think about types in C# is as follows: a type is a classification that can be applied to an expression. An expression is classified as being of a particular type if a proof exists that shows how the expression may be legally classified as that type, according to the rules of C#.

For example, suppose we are attempting to work out the type of the expression "1 + 2.3". We begin by working out the type of the expression "1". The rules of C# give us that; an expression of that form is always classified as an int. We work out the type of the expression "2.3". Again, the rules of C# tell us that an expression of this form is classified as "double". What is the type of the whole expression? The rules of C# tell us that the sum of an "int" and a "double" is classified as a "double". So the type of this expression is "double".

That's what the compiler does when it performs type analysis: it constructs proofs that particular expressions can legally be classified in particular ways, or, if the program is erroneous, it tells you why it was unable to construct a proof.

But all a type is, at this level, is simply a classification. You can do the same thing with any domain. You say that in the domain of positive integers, certain numbers are classified as "odd" and certain numbers are classified as "even". Certain numbers are classified as "prime" and "composite". If you want to classify a number, say, "123", then you might write a proof that shows that "123" is classified as both "odd" and "composite".

You can make up any classification you want, and you know what you just did? You just made a type. You can classify numbers into "the sum of two primes" and "not the sum of two primes", and "greater than four" and "not greater than four". And then you can combine them together into types like "even integers that are greater than four and not the sum of two odd primes". It is easy to determine if any particular integer is a member of this type; so far all integers that we've tried have been determined to not be members of that type. It is at this time unknown whether that type has any members or not; just because you can come up with a type does not mean that you know the size of the type!

A type system can allow any possible classification scheme. We could write C# so that "odd" and "even" and "prime" and "composite" were subtypes of "int". We could write C# so that any property of integers that you can write down is a subtype of int! We do not do so because such type systems put an enormous burden upon the compiler; compilers that work with such type systems are very complicated, very slow, and can get into situations where they have to solve impossible problems. The designers of the CLR and C# built the type system that we have such that the compiler can (usually) be extremely fast in classifying expressions into types.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 1
    I've often wondered about this. Would it be possible in a C#-like type system to subtype In32 into PositiveInt32, NegativeInt32 and ZeroInt32, and use the type properties to define the results of expressions like `PositiveInt32 * PositiveInt32 = PositiveInt32`, `PositiveInt32 * NegativeInt32 = NegativeInt32` and `PositiveInt32 + NegativeInt32 = Int32`? Every time I tried I got stuck somewhere but I'm not sure if it's just because I haven't spent enough time on it or because it doesn't actually work. – configurator Jul 19 '11 at 21:06
  • 1
    @configurator: Sure, that's possible. But if you really want a type system that is suitable for mathematical objects, check out the Agda type system. I am just learning about it myself; it looks pretty neat. – Eric Lippert Jul 19 '11 at 21:22
  • thank you Eric for Sharing your knowlege ,your answer really helped me(and us). – siamak Jul 20 '11 at 07:12
3

No, it's not correct to use "type" and "class" interchangably.

A type can be any of:

  • A class
  • An interface
  • A delegate type
  • An enum type
  • A struct
  • A pointer type
  • An array type (which is also a class)

As far as I can see, the C# spec doesn't really "define" the word "type". Even as early as the introduction it talks about C# having a "unified type system" without defining what a type is.

I suspect that for most developers, giving examples of what you mean by the word "type" is simpler and more communicative than trying to define the word accurately.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • its great to see you jon on this post ,if you got asked in a class that what is Type then whats your answer,my problem is i know what is it but i cant say what is it .and is it correct to say that Type covers a data structure? – siamak Jul 19 '11 at 09:57
  • @siamak: I think I would talk about it in terms of a unit of data and behaviour. But it's definitely hard to define precisely... – Jon Skeet Jul 19 '11 at 09:58
  • What about `Array`? That is also a type: http://msdn.microsoft.com/en-IN/library/2hf02550(v=vs.90).aspx – nawfal May 13 '13 at 17:46
  • @nawfal: Arrays are classes, but I agree they're a bit different. Added. – Jon Skeet May 13 '13 at 18:10
  • @JonSkeet so are delegates isn't it? But I think its worth adding them separately as type. – nawfal May 13 '13 at 18:23
  • @nawfal: Yes, that's true. (Anyway, I've added them now.) Note that it's "array types" which I've added - not just `System.Array`. Big difference. – Jon Skeet May 13 '13 at 18:24
  • @JonSkeet yes I understand that. – nawfal May 13 '13 at 18:25
1

You shouldn't use type and class interchangeably.

This is an interesting read regarding types.

Note that types include structs, interfaces, delegates, pointer types and enum constructs as well as classes.

George Duckett
  • 31,770
  • 9
  • 95
  • 162
  • what I can understand from that is for developing a "Type" we must creat a class that has those features .I mean that the problem is still exist Type---->class and class----->Type.!!! – siamak Jul 19 '11 at 10:15
  • 1
    That's true, you could create a class to develop a type, **but** there are other things that are types, listed in my answer. – George Duckett Jul 19 '11 at 10:44
  • I mean if somebody asked me what is or who is FireMan ,its not true to tell he is man of fire , at least its not completly true and clear . – siamak Jul 19 '11 at 15:06
1

Here goes...

A type is anything that can be instantiated (my definition, not MSFT's).

An interface can be instantiated in the sense that there must be another type that implements the interface.

Anonymous types are types for which there is no class definition, but they can be instantiated.

Any type may inherit from another (non-anonymous) type. We then call that other type the base type.

EDIT: As Jon Skeet remarked, static classes cannot be instantiated, so my definition falls flat. Maybe it should be "anything that can be instantiated, OR a static class"...

Roy Dictus
  • 32,551
  • 8
  • 60
  • 76
  • That is true... Would they be considered types also? Probably... However, even in a static class, something has to be instantiated so that its code can be executed... Intriguing :-) – Roy Dictus Jul 19 '11 at 10:01
  • Yes, they're certainly types. And no, nothing has to be instantiated (or at least no instance of the type has to be created) to call a static method. – Jon Skeet Jul 19 '11 at 10:05
  • "An interface can be instantiated in the sense that there must be another type that implements the interface." This is false. There is no requirement, enforced by either the compiler or the runtime, that an interface must have at least one concrete implementation. Yet, interfaces are still types. – jason Jul 19 '11 at 19:37
  • "Anonymous types are types for which there is no class definition, but they can be instantiated." This is false. The compiler generates the class for you. Anonymous types are merely lacking a name that you can refer to in source. – jason Jul 19 '11 at 19:49
  • 1
    @Jason - "... for which there is no class DEFINITION". Not the same thing. – Roy Dictus Jul 20 '11 at 06:20
  • 1
    @Jason: When I write "An interface CAN BE INSTANTIATED in the sense..." you say, "This is false, an interface doesn't need an implementation." Did I say that it needed an implementation to be a type? No, I said it needed an implementation in order to be instantiated. Get your quotes right before you contradict and downvote. – Roy Dictus Jul 20 '11 at 06:25
1

The best workaday answer I can come up with is:

A type is a collection of values, a collection of operations on those values, and a name to make it unique.

If you are looking for a deep answer about what a type fundamentally is from a computer science perspective, I don't think you'll find it in the C# documentation. Types are something that most of us use successfully in our daily lives without having to pin down their exact definition. But if you really want to know I think you'll find better answers in the programming theory and languages community (specifically, ML and Haskell) where people take great care to precisely formalize what they are talking about.

The Wikipedia entry for Type System is a good place to start.

Corey Kosak
  • 2,615
  • 17
  • 13
  • good point ,thanks for the great suggestion,could you please introduce me some good computer Science and teory Q&A sites or Forums,I know nothing about that,thanks again – siamak Jul 19 '11 at 14:48
  • Types need not have names. What's the *name* of the type "array of pointers to integers"? What's the name of an anonymous type? Array types, pointer types, anonymous types and constructed generic types arguably do not have names at all. It is the *declaration* of a type which has a name. – Eric Lippert Jul 19 '11 at 14:58
  • 1
    Leaving aside the question of names: your definition is reasonable for a working definition but quickly runs into set theory problems if you try to use it as a formal definition, in fact, the very set theory problems that the theory of types was invented to address! If a type is a collection of values, *is a type also a value*? If so, can a type be a member of itself? And if so, then can you have the type that is all types that are not members of themselves? And hey, we've got Russell's Paradox once again. – Eric Lippert Jul 19 '11 at 15:00
  • I don't know very much about the topic, so I can't provide you with the resource that will succinctly answer your question. However I'm happy to tell you about two interesting books I'm currently trying to read: (1) http://learnyouahaskell.com/ (2) "Types and Programming Languages" by Benjamin Pierce. They are both well-regarded and very well written, though may be more info than you were looking for :-) – Corey Kosak Jul 19 '11 at 16:37
0

Classes and types are not interchangeble. A class is always a type, but a type is not always a class. Structs and interfaces, for example, are type, but not classes.

Rik
  • 28,507
  • 14
  • 48
  • 67
0

"type" is simply short for "data type". Any variable you use has some data type, be it a so called "simple type" (like int or long) or a "complex type" like a struct or a class.

While a class is always a type, not every type is a class. For example, int is a type but not a class. C# has the feature that for every simple type there's also a representing class (bool => Boolean).

You can not use class and type interchangeably, but it will mostly be understood if you do :-)

Thorsten Dittmar
  • 55,956
  • 8
  • 91
  • 139
  • 2
    `Boolean` isn't a class, it's a struct. `bool` is simply an *alias* for the `Boolean` type. – Jon Skeet Jul 19 '11 at 09:59
  • @Thorsten, it seems you're confusing this with Java. There, `boolean` and `Boolean` are different types (one is a value type, the other a reference type). In C#, `bool` and `Boolean` are the same. – svick Jul 19 '11 at 19:31