On classes in declarations

Matthew Tuck matty@box.net.au
Tue, 01 Dec 1998 20:07:18 +1030


Ursula Dreier wrote:

> Not only class names (that is, literal constants) are allowable as a
> type, but also expressions, as long as they yield a class at compile
> time and give the editor a clue about the base class. Consider the
> following:
> How about that?

So are you saying that you're ensuring myCopy only takes the class of
x?  You could do this with bounded generics, like:

function CopyOMatic {implicit AnyNumber < Number}(X : AnyNumber)
   MyCopy: AnyNumber := X
   return MyCopy
end function

Note the "implicit", meaning that you don't have to actually specify the
type in the generics, you can just call it normally.  This is probably
pretty much what you had in mind, except I single out a special name
where you use type operators.

> There need only be one copy of the compiled function CopyOmatic because
> only items of name space Number will be referenced from within that
> method (except for virtual functions, but that's done dynamically &
> poses no problem), as opposed to the template function/class mechanism
> of C++ where different incarnations of the code will be produced for
> each different parameter set.

Generally object-oriented languages have done that I think.  C++ can't
because it doesn't have an generics interface (a contract between the
generic class and client), meaning whether it works can't be known until
instantiation.  Ada does, but I think most implementations usually do
the same.

I think the reason is that with generic types, you're not sure of their
size, so you have to work out the size of the object, although it's not
an insurmountable problem.  With variable-as-pointer in OO, the problem
goes away, but I think we should be trying to optimise objects into
other objects, which was standard in the pre-OO days and is much more
efficient.  In this case we still have the problem.

> Of course we are not limited to the ClassOf method, we could as well use
> BaseClassOf (x) or CommonAncestor (x, y) - you name it, as long as it
> can be evaluated at compile time.

That's certainly an interesting extension, but I think the problem is
that either you know what the common ancestor is, in which case you can
name it, or you don't, in which case the knowledge doesn't do much for
you, so you may as well declare the variable as taking Object.

BTW, how does this relate to variance?

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/