I have heard a lot about “type system”, “strongly typed language” and so on. Currently I am working on some .NET COM interop problem, which addressed “marshaling” a lot. And AFAIK, marshaling is quite about conversion between .NET types and COM types.
In many scenarios such as programming language, when talking about types, we are concerned about the logic meaning.
Now I am wondering: what does “type” mean physically? In a way we can watch & touch.
My current understanding is that “type” is nothing but the in-memory representation of an computation entity.
Many thanks to your replies.
Adding-1
Some quotation from MSDN:
Marshaling simple, blittable
structures across the
managed/unmanaged boundary first
requires that managed versions of each
native structure be defined. These
structures can have any legal name;
there is no relationship between the
native and managed version of the two
structures other than their data
layout. Therefore, it is vital that
the managed version contains fields
that are the same size and in the same
order as the native version. (There is
no mechanism for ensuring that the
managed and native versions of the
structure are equivalent, so
incompatibilities will not become
apparent until run time. It is the
programmer’s responsibility to ensure
that the two structures have the same
data layout.)
So as far as Marshaling is concerned, it is the layout matters.
I think there are three aspects to “types” in programming (and they probably overlap, so don’t take this as a hard-and-fast separation):
A type is an element of a set of types, and every program/assembly/unit defines such a set. This is the most theoretical idea I can think of and is probably most useful to logicians and mathematicians. It is very general, and it allows you to define the idea of a type system on top of it. For example, a programming environment might define a relation on those types, e.g. the is-assignable-to relation.
A type is a semantic category. This is a linguistic or cognitive idea; in other words, it is most useful to humans who are thinking about how to program the computer. The type encapsulates what we think of as “things that belong in a category”. A type might be defined by a common purpose of entities. This categorisation according to purpose is, of course, arbitrary, but that’s okay, since the declaration of types in programming is arbitrary too.
A type is a specification of how data is layed out in memory. This is the most low-level idea I can think of. Under this point of view, a type says nothing about the purpose or semantics of the data, but only how the computer is going to construct it, process it, etc. In this idea a type is somewhat more like a data encoding or a communications protocol.
Which meaning of type you go by depends on your domain. As already hinted, if you’re a logician doing research on how to prove properties of a program, the first definition is going to be more useful than the third because the data layout is (usually) irrelevant to the proof. If you’re a hardware designer or the programmer of a low-level system such as the CLR or the JavaVM, then you need the third idea and you don’t really care about the first. But to the common programmer who just wants to get on with their task, it is probably the middle one that applies.