Java Type System
in [Java Programming]
|
From: Lew on 18 Mar 2010 00:29 Mike Schilling wrote: > Putting the following down on paper (OK, pixels) helped me to understand how > generics extend the Java type system. ... 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
From: Roedy Green on 18 Mar 2010 03:55 On Wed, 17 Mar 2010 15:55:53 -0700, "Mike Schilling" <mscottschilling(a)hotmail.com> wrote, quoted or indirectly quoted someone who said : >Yes, Roedy, I know what thty are, but they're not relevant to what I was >exploring. > You were complaining that generic docs do not cover autoboxing and widening. I was pointing out why there was no reason to expect them to. -- Roedy Green Canadian Mind Products http://mindprod.com Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, �How would I develop if it were my money?� I�m amazed how many theoretical arguments evaporate when faced with this question. ~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.
From: Roedy Green on 18 Mar 2010 03:57 On 18 Mar 2010 01:43:11 GMT, ram(a)zedat.fu-berlin.de (Stefan Ram) wrote, quoted or indirectly quoted someone who said : >. Possibly Roady was not the only one > who was not reading it to the end My comment still stands whether you read the whole post or not. -- Roedy Green Canadian Mind Products http://mindprod.com Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, �How would I develop if it were my money?� I�m amazed how many theoretical arguments evaporate when faced with this question. ~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming.
From: Thomas Pornin on 18 Mar 2010 07:36 According to Lew <noone(a)lewscanon.com>: > "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. It may be noted that this is the road that C++ took, and it proved very slippery. C++ tries to express assertions as types, and it mostly leads to oversized and slow compilers, rather than the powrful compile-time bug detection that was consistently promised but less consistently achieved. To some extent, Java was designed as an effort to do programming "not like C++". In my view, "type-oriented programming" is not next-gen but previous-gen, and generics are a step "back" (at least in time). Generics were added because something had to be done about container types (List, Map...) but in the grand view of programming languages evolution, they represent a kind of failure. I am not claiming that generics are ill-designed by themselves; hard and smart work went into them, and they do what they were meant to do. I claim that they are a revival of an old theme, and flow opposite to the rest of the design of Java. --Thomas Pornin
From: Lew on 18 Mar 2010 08:43
Thomas Pornin wrote: > It may be noted that this is the road that C++ took, and it proved very > slippery. C++ tries to express assertions as types, and it mostly leads > to oversized and slow compilers, rather than the powrful compile-time > bug detection that was consistently promised but less consistently > achieved. Java is rather the opposite - with generics, it expresses types as (compile-time) assertions. I'm using "assertion" in the general sense here; this has nothing to do with the 'assert' keyword. I do not see that generics has noticeably affected Java compiler size or speed, and it certainly has added powerful compile-time bug detection to Java. -- Lew |