Further Quesa changes

[Roger H. <rog...@mi...>]

As most of you are aware, I have been changing Quesa so that
what are is essence virtual methods are not found by the old
mechanism of look up of the method name in a hash table,
but rather by holding the address of the method in an
extension of the class info for the class.

Whilst writing this I have retained the test on whether the method
is NULL before calling it, but I now think that many of these tests
could be done at class registration rather than on the call of a method.

For instance, the root class provides a kQ3XMethodTypeObjectDispose
method, and every class in the hierarchy has the option of overriding 
it,
but if it should return NULL, then Quesa calls the meta handler of the
parent classes up to as far as root if necessary. So it is impossible 
for
the method pointer for this method ever to be NULL, so there is really
absolutely no need to test for NULL.

There are cases where a method pointer can be NULL, for instance
the class Group has many NULL pointers, and this is very similar to
the C++ language having a class with methods assigned ' = 0 '. In
that cases objects of the class cannot be made. In our cases I do
not think that there is any point in making an object of type Group
as you can do practically nothing with it. Classes derived from Group
are of course useful, as they fill in the missing methods.

There are also legitimate cases where a method can be NULL, for
instance if a class adds only instance data without pointers, then
there is no reason to provide an instance data destructor method.

It seems that these legitimate NULL methods are those which do
not inherit from their parent classes.

What I propose is that we have a new boolean in the class info
called 'abstract', meaning it has one or more inheriting methods
which are NULL (i.e. pure virtual in C++ parlance). If any attempt
is made to create an instance of a class for which 'abstact' is
true, then a failure would be returned (and in the debugging
version an assertion error produced).

As this would mean that no objects could be created which refer
to a class where an inheriting method is NULL, then all the tests
for NULL could be taken out, saving more runtime overhead.
There would of course be similar tests at class registration but
these would only be done during initialisation. The only new
head would be a single test at the creation of each instance, but
as we are allocation (and clearing) the data, a single test is
swamped by the processing needed, and in 99% of cases it
is also swamped by the savings I have already made .

May I go ahead?

Roger.