Re: First stage of Quesa changes now complete

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

To improve on part of my suggestion earlier how about having in each
of the new classes an enum, something like:

	enum
		{
		depth =    <<<our parent class>> ::depth + 1 ,
		classType = <<< our type >>>
		} ;

so for E3Shared for instance :

	enum
		{
		depth = OpaqueTQ3Object::depth + 1 ,
		classType = kQ3ObjectTypeShared
		} ;



> One possible optimisation would be to hold an array of 6 elements in
> the E3ClassInfo record. Six being the maximum
> depth of the built in class hierarchy. Then for example, a class such
> as Display Group, element zero would contain kQ3ObjectTypeRoot,
> element 1 would contains kQ3ObjectTypeShared,
> 2 = kQ3SharedTypeShape, 3 = kQ3ShapeTypeGroup,
> 4 = kQ3GroupTypeDisplay and 5 and 6 would be zero. There would
> also have to be something like an enum for each class giving
> its depth in the hierarchy. Following our example, there would be
> a kQ3GroupTypeDisplay_Depth which would be 4. Then where we
> current test again a constant class type such as kQ3GroupTypeDisplay
> we could instead call a macro , something like
>
> OBJECT_IS_CLASS ( theObject, kQ3GroupTypeDisplay )

This becomes

OBJECT_IS_CLASS ( theObject , E3DisplayGroup )

>
> which would expand to be
>
>  ( (theObject)->IsClass ( kQ3GroupTypeDisplay , 
> kQ3GroupTypeDisplay_Depth ) )

( (theObject)->IsClass ( E3DisplayGroup::classType , 
E3DisplayGroup::depth ) )

>
> and OpaqueTQ3Object::IsClass would be an inline which would do this
>
> return theClass->typesArray [ depth ] == classType ;
>
> As in the inline, 'depth' would be a constant, this should optimise out
> as a simple test against a value at fixed offset in the class record.
>
> If it were not of the correct type, then either the entry would be the
> class type of another type, or zero if the object were of a type at
> a lower depth in the class hierarchy.
>
> Of course you will be thinking about user defined classes, but we never
> need to test against them as constants, the existing code would be 
> used.
>
> Anyone see any holes in this proposal?
>
>

The rest is the same.

Roger.