In Relation To

About two years ago, a co-worker asked me innocently: What are scalar types anyway?

I realized that I had used that term one too often and he was really asking if I can define it, not just use it.

On my way to the JavaPolis conference I had some time to write up what I understand about /scalar types/. The truth is, I had a lot of time, because my train got the wrong route (twice!), and we even had to go backwards several times.

Just to make this entry even more exciting, I'll also explain what I understand as a /variable/ and a /value/.

A type names a /set of values/. So, a type has a name, we know that. But what is this set of values? According to Chris Date, a value is an /individual constant/. Now, stop thinking in software terms, and think about information and data. A value has, by definition, no location in time and space. For example, we don't know where or when the value Hibernate is located, this question doesn't even make sense. It's a value nevertheless, just as the number 4 and the number 2.

We know that in a strongly typed language such as Java, every value has to have a type. This means that every value in our software carries its type with it. Instead of working with value literals, as I did in the previous paragraph, we assign them to variables. A variable gives a value a location in time and space. In Java, the type of a value is associated with the variable.

String projectName;
projectName = "Hibernate"

In the first line, we declare that String is the type of the variable projectName. The values that can be assigned to projectName are therefore limited to the set of values allowed for the String type, i.e., all character strings. In the next line, we assign the value Hibernate to the variable projectName. The assignment operator (=) checks both operands for compatibility: Is the given value in the set of values allowed for the variables type? Strong typing means that this check is performed for all operations, including all method (operator) calls, not only assignment.

Let's talk about types in Java. We have built-in types such as String, but also custom user-defined types, such as Project. But a Java /class/ is only the mechanism used for type declaration and implementation. Sometimes we are sloppy and say a class is a type, but strictly speaking, it is not. A type is all externally visible elements of a class, that is all operators (methods) and components (attributes) declared public. We just use the mechanism of a class to define this, and of course, to implement the actual (internal) representation. So the following class defines and implements the Project type:

public Project {

   public String projectName;

   public void makeOpenSource() {
      ...
   }

   public Team getProjectTeam() {
      ...
  }

}

The Project type has one component and two operators. But where is this set of values defined?

Consider the type Object in Java: This type implies a set with all possible values. So, in fact, the set is implicit if you create a type. In other words, if you declare a variable of type Object, you can assign whatever value you want. By creating a type (writing a class or interface), you narrow that set. For example, a type Project might imply a set of all possible projects. You can of course further restrict the allowed values by adding constraints to that type (only projects with a name shorter than 10 characters), but thats not the issue here.

Back to the initial question: A scalar type is a type that is /encapsulated/, that is, it doesn't have any user-visible components. The Project type in the example above is non-scalar, it has the user-visible component (attribute) projectName.

On the other hand, the Team returned by the select operator getProjectTeam does not reveal a component, but only gives us a part of the possible representation of a Project. We simply don't now (and shouldn't care) if the Team returned is internally a component (attribute) of the Project or something completely different. The implementation is hidden.

If we follow the Best Practices for POJOs (or JavaBeans), we automatically create scalar types. Adding a select operator such as getProjectName and removing the public visible component projectName would make the example Project type scalar, that is encapsulated or atomic.

Keep in mind that /scalar/ is not related to /complexity/ in any way. Just because we call Java primitives scalar, doesn't make all scalar types primitive.