Question 1 of 10

Question 1 (10%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

A data type is a classification that specifies which kind of values a variable or expression may hold, together with the set of operations that are legal on those values and the way those values are represented in memory. Formally, a data type can be described as a pair: a domain (the set of legal values) and a set of operations defined over that domain, plus, in most languages, a rule for how the compiler or interpreter checks that operations are used consistently with the domain (its type system). Defining a data type therefore does two jobs at once: it tells the language what a value "is," and it tells the language what you are allowed to "do" with it — an operation not defined for the type (e.g., taking the square root of a boolean) is rejected, either at compile time (static typing) or at run time (dynamic typing).

A simple built-in example is the integer data type: its domain is the (machine-representable) set of whole numbers, and its operations include addition, subtraction, multiplication, integer division, and the relational comparisons (<, ≤, =, ≠, ≥, >). The representation is typically a fixed-width two's-complement binary word, which also implicitly bounds the domain and defines overflow behaviour. In an object-oriented language, a programmer-defined class generalizes exactly this idea to a user-defined datatype: the class's fields describe the domain (the legal combinations of internal state an instance may hold), and its public methods are the operations legal on that domain. A Money class, for instance, might restrict its domain to a non-negative integer number of cents plus a currency code, and expose operations such as add, subtract, and convert that enforce currency-matching rules the language's built-in numeric types know nothing about — which is precisely why classes are described as the standard mechanism for defining new, application-specific data types in an OO language: they let the programmer extend the type system with exactly the same domain-plus-operations contract the built-in types already follow, while also hiding the internal representation (encapsulation) so client code can only interact with an instance through its declared operations.

This domain-plus-operations view also explains why a data type is more than "a set of bits." Two variables can share an identical bit pattern (say, the 32-bit pattern for the integer 65) yet be entirely different data types — one an int, one a char representing the letter 'A' — because the type also determines which operations are legal and how the bits are interpreted (arithmetic vs. character semantics). A class-based datatype makes this even more explicit: two classes with identical field layouts (e.g., a Point and a Vector2D, both an x and a y coordinate) are distinct types precisely because they expose different operations and enforce different invariants, even though their underlying storage is the same.