[ruby-talk:9797] Re: 101 Misconceptions About Dynamic Languages

Josh Stern ([e-mail]) wrote:
> There is a real, non-trivial, example of template
> genericity being used to express mathematical ideas
> in the CGAL library:
> 
> http://www.cgal.org/Manual/doc_html/frameset/fsKernel.html
> http://www.cgal.org/Manual/doc_html/frameset/fsBasic.html
> 
> How to do such things in Ruby in full generality (efficiency
> aside)?  

To begin with, for the most basic use of generic types, no additional
effort is necessary--Array and Hash are obvious examples. For more
advanced schemes, it may be best to avoid the elaborate and
unnecessarily complicated maze of C++ templates and return to simpler
approaches. For instance, the instantion of a parametric type A[X] as
A[T], where X is a formal parameter and T a concrete type, can be seen
as specialization inheritance from A[X] with X = T. What we need for
this to work is to be able to work with types as first class
objects--something that C++ can't do, but Ruby can. Instantiating formal
parameters of generic types is basically constraining a family of
objects along one more dimensions. While I believe that somebody
mentioned earlier that genericity and inheritance are orthogonal
concepts, the opposite is true: generics introduce a classical is-a
relation, generally with full substitutivity (modulo the usual
covariance issues).

If the full machinery of inheritance is thus applied to a language, you
will get something like Beta's virtual patterns--where you cannot only
redefine functions along an inheritance hierarchy, but also types,
exceptions, etc. A similar approach was used by Meyer in the first
edition of Object Oriented Software Construction to avoid the
introduction of generic types. It has also been rediscovered as the
concept of "virtual types" for the purpose of introducing genericity in
Java.

A straightforward implementation would pass types, and whatever other
generic parameters you have, as arguments to 'new', to be stored in type
variables. Instantiating the formal paramaters would then be the
equivalent to performining currying on 'initialize'. Variants would be
having functions returning types, which can then be redefined, or
aliasing type names to constants. (And of course, when I'm referring to
types, just about any type of object can be substituted.)

The implementation of Z_n, for instance, should be a straightforward
exercise. The need of generics for a polynomial ring is not equally
obvious; we only need a type parameter as a simple case of a factory
pattern, and even this could be avoided if desired.

A lot of the problems that you have in many statically typed languages
just go away when you have types as first-class objects. It should also
be noted that just because something is part of C++ it should not
necessarily be added to another language; in fact, the converse is
generally true.

[...]

				Reimer Behrends