Re: Java Type System

Mike Schilling wrote:


Nicely done.

Abstracting one layer, Mike has pinned an aspect of Java that particularly
excites me, its type expression system.

"Type-oriented programming" is next-gen object-oriented programming. Taken
together, Java interfaces and generics form a declarative syntax of assertions
about type relationships.

Properly used, this syntax lets the programmer direct the compiler to enforce
assertions that lock a program into correct behavior. Typifying the benefit,
we eliminate runtime type checks (or crashes from lack of enforcement), e.g.,
that a collection contain only 'Person' instances.

In cases where we need a runtime type check to cooperate with compile-time
enforcement, we coerce a 'Class<T>' variable into the mix, usually a private
final member. A little judicious reflection off that instance (I use the name
'this.clazz') with conventions like that 'T' not need a complex constructor,
and you can do anything you need for type 'T'. The compiler infers type
correctness from the 'Class' instance.

   public <T> T find( Class<T> clazz, Object key );

or

   public <T, K> T find( Class<T> clazz, K key );

which lets you call

   Person person = find( Person.class, name );

If the generic were applied to the type, you store the class in the instance
rather than the argument list, e.g.,

   public class PersonManager extends Manager<Person, String>
   {
     public PersonManager()
     {
       super( Person.class ); // stores in Manager#clazz
     }
     @Override
     public Person find( String name )
     {
       return getEm().find( getClazz(), name );
     } // actually, this duplicates the superclass code
       // sorta - superclass is generic
   }

Superclass 'Manager<T, K>' left as an exercise. I think of 'getEm()' and
'getClazz()' as protected final methods.

--
Lew