What is an object?

The most fundamental question is: What is an object? The spectrum in existing object-oriented languages is wide. Some languages (e.g. Smalltalk) declare that Òall information in the system is represented as objectsÓ [Goldberg 1989, chapter 6]. Simple data types, classes and even control structures are implemented as objects. Other languages (such as C++) regard only data of some user-defined, ÒlargeÓ data types as objects. Instances of simple types (such as integer numbers and characters) are not objects, nor are the classes themselves. Even user-defined data does not have to be an object. Java takes a compromise route: Simple data types (e.g. integer) are not classes (and instances are therefore not objects), but there is also an integer object, for cases when it is needed.

The issues can be summarised in the following four questions:

Are control structures objects? Are classes objects?

Are all user-defined data structures objects? Are scalar/builtin types objects?

In the following sections we discuss each of these questions.

Are control structures objects?

Smalltalk takes the object-oriented paradigm further than any other language. Not only are instances of data objects, but the elements of the programming language themselves are objects, which can receive messages and return results like any other object. The language constructs follow the model of the data on which the language operates.

While this idea has a fascinating appeal to language designers (because of its striking elegance and uniformity) we believe that this view is not helpful for beginning students. One problem is that the treatment of control structures as objects (with message passing syntax for the use of control structures) results in very unusual syntax for program control. For example, the following Pascal statement

if (x > y) then

begin

max := x; index := index + 1;

end

CHAPTER 6: THE BLUE LANGUAGE

x > y ifTrue: [max <- x.

index <- index + 1]

We believe the Smalltalk syntax not to be as easy to read initially as the Pascal syntax. Moreover, most other mainstream languages (C++, Java, Eiffel, Ada) use a syntax that is much closer to the Pascal variant. Because of the principles of readability, and the role of Blue as an entry point to other mainstream languages, Blue does not regard control structures as objects. Control structures are independent of data types.

An interesting approach to a related topic is implemented in the language Beta. Beta defines a pattern as a syntactical unit. A pattern is a very powerful construct which can be used to represent a wide range of language entities, such as classes, routines, processes and block structures. The idea is similar to the Smalltalk approach: using a unified model for representing various language entities results in a very elegant and powerful system. Because an instance of a class and an instance of a process, for example, are described in the same fashion, processes automatically become objects and can be treated in the same way as objects.

For Blue, we have decided not to attempt such a unification of concepts. While powerful once it has been mastered, it can cause considerable confusion for beginners. Both readability and clarity of concepts suffer under such a unification. Different language elements, such as a data item and a control structure, are inherently different and can be used in different ways. Equally, a routine is not the same as a class. Making them look the same does not help beginners understand their respective purposes and their differences. For the teaching of concepts it is best to represent each of the concepts in its own, clear style. The expressiveness of the language will necessarily suffer, but the clarity won by this decision is well worth the trade-off.

Are classes objects?

The question as to whether classes are objects is closely related to the previous one. In Smalltalk, for instance, objects are instances of a class. Classes themselves are also objects, and thus instances of another class (a meta class). By defining this, Smalltalk has a powerful mechanism for reflection. Since classes are objects, they may be dynamically created. In this way, Smalltalk can dynamically introduce new types (and thus new code) into a running application.

Most other languages (especially statically typed languages) do not regard classes as objects. Classes are compile time constructs, which do not exist at runtime. Objects are runtime constructs which do not exist at compile time. This distinction makes the respective roles of classes and objects very clear. For similar reasons to those given for the previous question, Blue adopts this view. The distinction of different concepts serves to add clarity and emphasises their respective purposes.

Java tries to get the best of all worlds: while classes and objects are orthogonal concepts, it adds a standard class library for reflection. This library allows the user to create and compile classes dynamically, thus adding the power of reflective systems.

CHAPTER 6: THE BLUE LANGUAGE

Whether a mechanism like this would be helpful for Blue does not need to be decided at this point. Since this is implemented through a class library, it does not impact on the language design.

Are all user-defined data structures objects?

We have basically answered this question in the requirements section. One of the requirements we listed was that the language should be a pure object-oriented language. We did not want a hybrid language. Following this requirement dictates that all user defined structures should be objects. All code users write is part of a class. Blue does not support functions independent of classes.

Are scalar types objects?

Are instances of simple, built-in data types, such as integers, characters, booleans, etc., objects? There are many arguments either way.

Efficiency and syntax are frequently used arguments against the view of simple data as objects. It is not efficient, it is often argued, to implement integer numbers as objects. The memory and runtime overhead would be too great. The second argument is syntax: if integers were objects, for consistency reasons they should use object method syntax for invoking their operations. Adding the numbers 3 and 4, for example, should be written as

3.add (4)

rather than the more customary

3 + 4

This syntax, because of its unfamiliarity, might negate the advantage of having a unified concept and cause more confusion than the proposed benefits.

The main argument for the definition of simple data as objects is unification of concepts. The whole object model could then be explained by one general concept without the need for seemingly arbitrary exceptions. Passing an integer as a parameter, for instance, would be no different to passing a user-defined object. There is one conceptual problem, though. Objects must generally be created before they can be used. But do we really want to force a programmer to have to create the numbers 3 and 4 before they can be added? This would be impractical and counter-intuitive.

Another strong argument for viewing simple data as objects comes from generic composition. All object-oriented languages support polymorphism. It is available through inheritance and, in many languages, through genericity. Making a distinction between simple data items and objects might lead to problems with combining them. A generic list class, for instance, might accept any object type as its generic type parameter. Thus, it allows the creation of a list of persons as well as a list of buttons. But can a simple type be used where an object is expected? In other words, can we create a list of integers? If a distinction is made between simple types and objects, this might lead to problems.

CHAPTER 6: THE BLUE LANGUAGE

Blue takes the view that all data are objects. In this aspect Blue differs from most mainstream object-oriented languages, with the notable exception of Smalltalk, which also views all data as objects. However, it differs from Smalltalk in many details.

The fact that all dynamic structures can be explained with a unified model is especially attractive for a teaching language. The disadvantages, however, must be addressed. The first was efficiency. There are two aspects to this. Firstly, since Blue is a teaching language, conceptual elegance takes precedence over efficiency. We can afford to make efficiency sacrifices. Secondly, the fact that simple types are conceptually the same as objects does not necessarily mean that they have to be implemented in the same way. Several optimisations are possible (and Blue implements them) for handling operations on simple, built-in object types in a more efficient way than general object operations. This can be achieved transparently without affecting the conceptual model.

The second disadvantage was syntax. To overcome this problem, Blue introduces a feature called ÒaliasesÓ. An alias allows a second, more convenient syntax for selected operations. So, for example, the expression

3 + 4

is an alias for the operation

3.add (4)

This allows the use of familiar syntax and eliminates the need to understand object calls to write the first, simple programs.

Some languages, Smalltalk and C++ for instance, use another solution to the same problem. In those languages, the syntax for object calls is defined to allow the symbol + as a valid method call. Thus the problem does not directly arise. No choice needs to be made as to whether to use object call syntax or infix notation because the infix notation is object call syntax. Blue does not follow this path because of the more complex object call syntax, problems with coherent interpretations (such as operator precedence) and the resulting potential for misuse. Since infix notation is a valid routine call syntax, it is available to all objects, including user defined ones. This makes it possible to use it in places where its meaning is not intuitively clear, possibly resulting in less readable code. (This issue is further discussed in section 6.15.3.) The difference with the alias mechanism is that it is a construct that is available for only a few, pre-defined operations. It is not available to the programmer as a general purpose mechanism, thus ensuring that all other object calls share a common syntax. Aliases are discussed in more detail in section 6.10.

The third problem was that of object creation. A user does not want to create integer numbers before being able to use them. This problem is solved through the introduction of manifest classes in Blue, as described in section 6.2.4.

CHAPTER 6: THE BLUE LANGUAGE