Classes and structs in C# share several characteristics:
they can be instantiated (absent restrictions to the contrary, as with abstract and static classes)
they can contain method and property implementations
the type's author defines the type's instance fields
We often use "class" and "struct" to distinguish between "reference type" and "value type", but sometimes it's useful to consider both types of types. Furthermore, "reference type" also includes interfaces and delegates, which are not classes. So "class" doesn't mean any reference type, it means "a reference _(fill in the blank)_".
For example, if reference and value type declarations were like this:
public sealed class ref String { }
public class val Int32 { }
instead of like this:
public sealed class String { }
public struct Int32 { }
then the word "class" could be used to denote the concept.
The best answer I've come up with here is "concrete type", but that would be confusing, since it could also refer to the non-abstract subclass of an abstract class.
Any suggestions?
EDIT
To clarify, I'm not seeking a word that can collectively describe instances of classes and structs. I'm trying to describe class types and struct types.
In other words, if "class" denotes a set that includes System.String, System.FileInfo, etc., and "struct" denotes a set that includes System.Int32, System.Collections.Generic.List<T>.Enumerator, etc., then I'm looking for the word that denotes the union of those sets.
EDIT 2
(In reaction to Jordão's answer) Another way to answer this question would be to complete the following sentence: "All C# method implementations must be declared as members of a _(fill in the blank)_".
I normally use the term "type" to refer to any of those elements: class, struct and even interfaces and enums.
I never really felt the need to talk about classes and structs exclusively, I would probably just say "class", and then differentiate them as needed.
The term type in C# can refer to any of:
Reference Types
object, dynamic and string
Class types
Interface types
Delegate types
Constructed class/interface/delegate types (e.g. List<string>)
Array types
Value types
Struct types
Enumeration types
Simple types (integral types, floating point types, decimal, and bool)
Nullable types
Pointer types
All of these are terms from the C# specification.
class, interface, delegate, struct and enum types are also called type declarations (or: user-definable types).
Depending on your point of view, you might also consider type parameters and void to be types.
However, there isn't any special term for "classes or structs". In the language of the C# specification, one would say:
All C# method implementations must be declared as members of a class or struct declaration.
I realize this question has a selected answer, but I believe I can offer a fresh insight that will still be helpful:
I think the word you are looking for may be Model. This term is used to mean several different things in CS, but the wikipedia article for mathematical model describes my intension.
In this context, a model is a description of a system in some meta language. A system can be fully expressed in terms of its three parts: structure; behavior; and, interconnectivity. Both .NET classes and .NET structs are compatible with this definition. Interfaces are not, because the behavior is not defined. You can only indicate the structure of method calls and member declarations and the type contracts for operations (interconnectivity). Enums may or may not be compatible with this definition, but as most frequently used are not, because they typically do not express behavior. The exceptions are enums for which bitwise operations are sufficient representations of meaningful set operations. With this precondition, I think its fair to classify an enum along with classes and structs.
As a side note, both interfaces and standard enums could be considered as systems by themselves, if extension methods were interpreted as intrinsic to the types they extend. However, neither the compiler nor I would consider extension methods to be intrinsic to the type of the first operand. A more accurate interpretation would be to consider both the enum/interface and the extension method as necessary components of a system. The difference between these component types that are extended and a class/struct/special-case enum is that the class/struct/special-case enum is a system in-itself, and therefore a subsystem of its containing system, whereas the component type is a component but not a system in itself.
It is probably worthwhile to clarify that, under this interpretation, the term model is analogous to a type, whereas the term system is analogous to an instance. A system could also apply to a larger composite, such as an assembly, but that is not what the question was about.
The statement "All C# method implementations must be declared as members of a model" seems to work. It also does not logically entail that "all models can contain custom method implementations", so we are safe in the special-case of set-theoretic enums. It would also work in the case where the modeled system is the composition of static extension method implementations and interfaces.
I find this to be a pseudo discussion. Point #3 can be said about enums and interfaces too, and the point about subclasses of abstract classes not fitting into the mix, I simply don't get. I think your own suggestion of "concrete types" is ok, but maybe you just want to talk about them as classes and structs, oh wait, but with the exception of subclasses of abstract classes and classes that implement interfaces. The reason that there is no term for what you are looking for might be that it is not a very useful concept in its own right.
EDIT:
All C# method implementations must be declared as members of a class or struct.
It should be Microsoft term. The origin of these notions is C++, where structs are just classes with all members being public. So, Microsoft cooked some new judging here, mixing some of C, C++ and Java. So they should invent also a terms.
Microsoft denotes them all as "types" which can be "value", "reference" and "pointer": http://msdn.microsoft.com/en-us/library/3ewxz6et(v=vs.100).aspx
But these notions do not gather only structs and classes.
So, if invent some custom term, we may take one from Pascal language, for example, where it is "record". Or some other terms can be coined from here: http://en.wikipedia.org/wiki/Object_composition
Both classes and structs are types which define objects. They are building blocks within an object oriented programming language. You can model both of them using UML or some other high-level object oriented modelling language. The choice between one or the other is an implementation detail.
Related
The paper Valued Conversions by Kevlin Henney gives a motivation for a so-called variant value type functionality, as well as an outline of a C++ implementation. It is a good read and it covers exactly what I would like to have available in C#: a general type that can hold values of different value-types.
I have not been able to find anything like this in C# though. Somewhat similar questions on SO have unsatisfactory answers and comments like "this is probably not what you want". This surprises me because it looks like fairly commonly required functionality. Henney's C++ boost::any class is widely used.
Is it not possible to create this functionality in C#?
Edit: Responding to one of the answers, I do not think that generics will do the trick. Using a generic requires the developer to know what kind of value-type the Variant variable is holding, and that type becomes immutable for that particular Variant variable as well. But the Variant type I am talking about should be able to hold different types. For example, a function Variant ReadValue() could read an entry from a file, parse it, fill the Variant value accordingly and then return it. The caller does not know in advance what kind of type will be contained in the returned Variant.
This is what generics are for. List<T> where T is anything at all. Generics provide both compile-time and runtime type safety.
You could create your own generic type to store any value you want. You could also cast anything to object and pass it around as such.
You can also use generic constraints to limit your type, such as wanting to only have T be a reference type:
public MyClass<T> where T : class
Or a value type:
public MyClass<T> where T : struct
See more here: http://msdn.microsoft.com/en-us/library/d5x73970.aspx
You can look into using dynamic for this as well.
The dynamic type enables the operations in which it occurs to bypass compile-time type checking. Instead, these operations are resolved at run time.
Type dynamic behaves like type object in most circumstances. However, operations that contain expressions of type dynamic are not resolved or type checked by the compiler.
From what I understand, using any in C++ is same as using combination of object and ChangeType method in C# with exception of having nice syntax for autoconversion from and into the any type. And without limitation just for value types.
Henney's article is quite old (year 2000). In a live lesson (London DevWeek 2008) I remember him explaining low coupling and implementing towards abstractions (interfaces) for the OCP (Open-Closed Principle). He was quite fond of generics and more so generic interfaces. So conceptually it's most probably exactly what he has written about back then, albeit I must admit I didn't read the article. C# generics are even a bit more robust then C++ templates, you should look at Covariance and Contravariance in Generics.
On another note:
What you can't do with generics are variable arity templates, which have been available for C and C++.
I'm writing an application using Roslyn to syntactically and semantically analyse C# source code. For each type defined in the source code being analysed, I would like to store whether it's a reference type (a class), a value type (a struct) or an interface.
What's the appropriate/official term for a type's type?
Example:
class A
{
//This type's type (A's type) is 'class' (i.e. a reference type).
}
If you want to know the official name, look into the official source: the C# language specification. Quoting from there (§1.3 Types and variables; emphasis mine):
There are two kinds of types in C#: value types and reference types. […]
C#’s value types are further divided into simple types, enum types, struct types, and nullable types, and C#’s reference types are further divided into class types, interface types, array types, and delegate types.
Then there is a table that describes those groups of types as category, and also this quote:
Five of C#’s categories of types are user-definable: class types, struct types, interface types, enum types, and delegate types.
Although later (in §4 Types):
The types of the C# language are divided into two main categories: Value types and reference types.
To sum up, the specification calls them categories of types, although its usage of that term is not very consistent.
In type theory, the type of a type is usually called its kind. That primarily describes the form of parameterisation of a type, although it can be used for other classifications, too. But I'm not sure whether it applies naturally to the sort of classification you are referring to here. It seems that C# does not have an "official" term for that either.
I've seen us use "kind" in the Roslyn source code, as in "there are 5 possible kinds of types that can be declared". However I don't think there is an officially defined term for this. I'd use "kind of type" or "kind".
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When should I use a struct instead of a class?
By Venkat K in the C# .NET forum.
29-Apr-09 07:38 AM
The only difference between "class" and "struct" is that a struct defaults to having public members (both data members and function members) and a struct defaults to public inheritance, whereas a class defaults to private members and private inheritance. That is the only difference. This difference can be circumvented by explicitly specifying "public", private", or "protected" so a struct can be made to act like a class in ever way and vice versa.by convention, most programmer's use "struct" for data types that have no member functions and that do not use inheritance. They use "class" for data types with member functions and inheritance. However, this is not necessary or even universallly acepted.
*(Can this be true)
That statement is entirely false when it comes to C#. I believe it may well be true for C++, but in C# the difference is between a value type (structs) and a reference type (classes).
It's not the only difference. Structs are value types and classes are reference types. Look it up on Google to find out more about the differences, which are too many to list in the minute I have right now.
Unless, as #BrokenGlass points out it's C++.
The statement you quote would be correct for C++, but not for C#. Here's an excerpt of what the C# Language Specification has to say about structs:
Like classes, structs are data structures that can contain data members and function members, but unlike classes, structs are value types and do not require heap allocation. A variable of a struct type directly stores the data of the struct, whereas a variable of a class type stores a reference to a dynamically allocated object. Struct types do not support user-specified inheritance, and all struct types implicitly inherit from type object.
Structs are particularly useful for small data structures that have value semantics. Complex numbers, points in a coordinate system, or key-value pairs in a dictionary are all good examples of structs. The use of structs rather than classes for small data structures can make a large difference in the number of memory allocations an application performs.
When I started OO programming many years ago I gained the impression that variables (if that is the right word) were either "primitives" (int, double, etc.) or first-class objects (String, JPane, etc.). This is reinforced by a recent answer on primitives in Java and C# (#Daniel Pryden: Are primitive types different in Java and C#?). However don't know whether C# ValueTypes are primitives, objects or some other beast such as second-class objects. I see that SO has only one use of the first-class tag so maybe it is no longer a useful term.
I did not find the Wikipedia article useful ("This article is in need of attention from an expert on the subject."). I'd be grateful for a taxonomy and current usage of terms, primarily related to Java and C# (though maybe other languages will shed enlightenment).
Clarification: I'd like to understand the term first-class and what its range of use is.
The notion of "first-class citizen" or "first-class element" in a programming language was introduced by British computer scientist Christopher Strachey in the 1960s in the context of first-class functions. The most famous formulation of this principle is probably in Structure and Interpretation of Computer Programs by Gerald Jay Sussman and Harry Abelson:
They may be named by variables.
They may be passed as arguments to procedures.
They may be returned as the results of procedures.
They may be included in data structures.
Basically, it means that you can do with this programming language element everything that you can do with all other elements in the programming language.
The problem is that "first class object" is not a well defined concept.
The normal usage is that someone says that an "object" is a class of thing that should have all of the properties X, Y and Z. But there are other things that don't have all of those properties, but they are sort of object-ish. So we'll call the former "first class" objects and the rest not "first class" ... and may be not objects.
The problem is that there are any number of views on the properties that a thing needs to have to make it a "first class" object. And no prospect of the people with opposing views coming to a consensus. (For example, a Javascript language expert might argue strenuously that an object is only first class if it is template-based.)
The only really solid insights about "first-classness" will be those that you can glean from the respective language specifications for Java and C#. And they only really apply within the scope of the respective languages / type systems ... and not across multiple languages.
So "first class Java object" or "first class C# object" might be meaningful, but "first class object" taken out of context is not.
Well that's my opinion ...
In .NET you don't have primitive types vs classes. Instead, you have structs vs classes, but structs share many of the features of classes (such as the ability to have properties and methods), and inherit from the Object class as well.
When you write int in C#, for example, it is just a language shortcut for the Int32 struct. You can do for example int i=int.Parse("34"), or even string s=1234.ToString(). In order to assign struct instances to variables of type Object, there is the boxing/unboxing mechanism.
In Java, on the other hand, you have indeed the primitive types vs classes dicotomy. So for example to perform operations on a variable of type int, you must use the auxiliary Integer class. That's one of the things that I don't like of Java compared to .NET.
EDIT. When you read about "first-class objects" (or classes), it means "fully-powered objects", that is, classes that have the same capabilities as any other system classes or user-made classes. This is to distinguish from "limited primitive types".
For each primitive data type in Java, the core class library provides a wrapper class that represents it as a Java object. For example, the Int32 class wraps the int data type, and the Double class wraps the double data type.
On the other hand, all primitive data types in C# are objects in the System namespace. For each data type, a short name, or alias, is provided. For instance, int is the short name for System.Int32 and double is the short form of System.Double.
The list of C# data types and their aliases is provided in the following table. As you can see, the first eight of these correspond to the primitive types available in Java. Note, however, that Java's boolean is called bool in C#.
From : http://msdn.microsoft.com/en-us/library/ms228360%28VS.80,lightweight%29.aspx
http://onjava.com/onjava/2003/05/21/delegates.html
in other words c# methods are first class object because we can pass it in another method. we can use methods like any other values(strings, numbers, user-created object).
Another example of first class objects that u can find uncommon in other languages but c# is Expressions
Frankly, I have no idea of what a "first-class object" is...
But I first found usage of a similar idiom in Lua documentation and mailing list, saying that functions are first-class citizens, or first-class values.
I let one of the authors of Lua to explain what it is: Programming in Lua : 6 - More about Functions
It means that, in Lua, a function is a
value with the same rights as
conventional values like numbers and
strings. Functions can be stored in
variables (both global and local) and
in tables, can be passed as arguments,
and can be returned by other
functions.
Somehow, this definition applies to objects in Java: you can store them in variables, in arrays, use them as function parameters and return them, use them as key of HashMap and other collections, etc.
Not sure if that's how the term is used for objects, but at least it makes sense... :-)
In a language like C, objects have to be made from scratch, using some tricks (re-creating C++, somehow...), so they are not first-class: you have to pass pointers around to manipulate them.
When we're talking about "first-class objects" by "objects" we mean some concepts of the language, not the objects that we create in that language. That is why there is also such terms like "first-class citizens".
So, for example, Java has following concepts - Java-objects, Java-primitives, fields, methods and other (by Java-objects I mean anything that is instance of Object type). I'd say that in Java both Java-objects and Java-primitives are first-class citizens in the language.
In C# we have some additional concepts that we can "test" for first-class properties. For example, delegates. We can assign delegate ot variable (give a name), pass it to the method as an argument, return it from method, incorporate in data structures (have a Dictionary of delegates for example). So I think we can say that delegates are first-class objects in C#. You can continue for other concepts of C# - events, properties...
Functional languages have concept of "function" and of course it is a first-class citizen in the any functional language. I'd say that we can call language a functional language if it has "function" as a first-class concept (name, pass, return, incorporate...).
So, if some language bring some concepts we can "measure" the power of this concepts in the language it self.
I don't understand it...
Why do they need a common base?
The question presupposes a falsehood. They don't need a common base type. This choice was not made out of necessity. It was made out of a desire to provide the best value for the customer.
When designing a type system, or anything else for that matter, sometimes you reach decision points -- you have to decide either X or not-X. Common base type or no common base type. When that happens you weigh up the costs and the benefits of X to determine the net value, and then you weigh up the costs and the benefits of not-X to determine the net value, and you go with the one that was higher value. The benefits of having a common base type outweigh the costs, and the net benefit thereby accrued is larger than the net benefit of having no common base type. So we choose to have a common base type.
That's a pretty vague answer. If you want a more specific answer, try asking a more specific question.
I think, mainly in order to have a type to refer to any object. An argument of type object could be a primitive type, a struct, a reference type, just anything. It is important to have such a type.
Then there are some common members that are implemented by every type, like Equals, ToString, GetHashCode. This could indeed be a common interface as well, but then you wouldn't inherit a default implementation.
Because its in the spec:
8.9.9 Object type inheritance
With the
sole exception of System.Object, which
does not inherit from any other object
type, all object types shall either
explicitly or implicitly declare
support for (i.e., inherit from)
exactly one other object type. The
graph of the inherits-relation shall
form a singly rooted tree with
System.Object at the base; i.e., all
object types eventually inherit from
the type System.Object.
There are several benefits to this design approach.
Some reasons why many / most are:
To provide common members such as Equals, Finalize, GetHashCode, ToString....
To help with boxing....
Java and C# took a different approach to this. It's mainly to do with performance.
If you imagine that every object can be nullable, then it has to be a pointer to a value, which can be changed to a pointer to null. Now this means that for every object you need at least a pointer and a chunk of memory to store the value.
Java has the concept of a primitive value, which is NOT an object. It doesn't have a pointer and it isn't nullable. This breaks the OOP paradigm but performance wise makes sense.
C# (or more correctly the CLR + BCL) attempted a good compromise, the ReferenceType and ValueType derivations. Anything that derives from ValueType are treated like primitives to the CLR, avoiding having an object reference. However this value can still be treated like an object via boxing, allowing you to have the performance benefits of primitive types but allowing everything to be treated like an object.
The real key difference between these things is the semantics of passing parameters to methods. If everything is an object, then you are passing references to the object, i.e the object can be changed by passing it to a method. Primitives and C# value types are passed by value, so they are effectively copied into the method call and the original value is unchanged.
It's the standard story of development. Try and get it right first, then see if you can optimise it later once you see the bottlenecks. Having pass by value semantics also allow you to prevent coding mistakes from mutability. (eg. passing a class vs a struct in C#)
ToString. For example.
Useful for Boxing and Unboxing
see reference
Every object in .NET shares common properties and methods. However, these are then divided into two categories: value types and reference types. Value types (ie, int) are stored on the stack, Reference types (ie, your custom class) are stored on the heap. Reference types store a reference to the actual data (thats on the heap). Value types directly contain their data.
You can read more over at MSDN:
http://msdn.microsoft.com/en-us/library/system.object.aspx
As a side note to other "answers" a struct is a value type, that also inherits from object.
Maybe the answer is that its assumed that we are programming object-oriented style/paradigm? A ball is an object. A sword is an object. An employee is an object. A purchase order is an object.
Some companies design their .NET (or Java or Ruby or PHP) applications to inherit from a common base class, so that they can all be treated the same way in their system. If I remember correctly from back in my old Java days... all EJBs share the same base class so that they can be managed and identified uniformly.