Next: Conclusions
Up: Everything is not an object
Previous: Misplaced methodsand modules
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:
- 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.
- System related criteria; Objects can be composed to form systems.
This
does not apply to indiscernables.
- 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.
- 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.
Jocelyn Ireson-Paine
Mon Jan 12 14:15:07 GMT 1998