The cure

Our prescription is threefold:

• Java needs a means of defining non-object data types. Such types will, like the object types, be able to have instance variables, though these will only be able to hold other data types. In effect, non-object types will just be structures, records, lists, and so on. Unlike the object types, they will not be able to have methods.

• Java needs modules. This should incorporate both non-object and object types, both with inheritance. The Functional Object Oriented Programming System (FOOPS) [FOOPS] and its treatment of modularity can be taken as a guide.

• Programmers (including those who write the built-in libraries) need criteria for deciding whether to implement something as aan object or as an indiscernable. We suggest, amongst others:
  1. Time related criteria; Objects can be said to change with time, since it makes sense to talk about an object retaining its identity even when some attributes change. This does not apply to indiscernables.

  2. System related criteria; Objects can be composed to form systems. This does not apply to indiscernables.

  3. Real world related criteria; Objects have semantics plus pragmatics while indiscernables have only semantics. In a program, an object that has no pragmatic connection with real-world objects is probably an indiscernable, and should be described as such.

  4. Definition related criteria; Indiscernables are commonly agreed. Objects are more programmer - dependent. Objects are ``thing-like''; indiscernables are partly ``thing-like'', but lack one essential property, that of individual identifiability. This is the Leibnitz Principle [Kneale], and simply says that two objects can be identified if and only if they have the same attributes.