Пропустить навигацию
1 3 4 5 6 7 Назад Вперед

forax

Записей: 101
forax@univ-mlv.fr

Resurrect dolphin Blog

Опубликовано: forax@univ-mlv.fr 14.10.2007
forax@univ-mlv.fr

Java kernel in jdk6 update 4 Blog

Опубликовано: forax@univ-mlv.fr 20.08.2007
forax@univ-mlv.fr

Java property (draft 3) Blog

Опубликовано: forax@univ-mlv.fr 13.05.2007
forax@univ-mlv.fr

@nnotation type or type @nnotation Blog

Опубликовано: forax@univ-mlv.fr 18.03.2007
forax@univ-mlv.fr

Meet me at FOSDEM Blog

Опубликовано: forax@univ-mlv.fr 20.02.2007
forax@univ-mlv.fr

Property Reloaded Blog

Опубликовано: forax@univ-mlv.fr 23.01.2007
forax@univ-mlv.fr

Property and interceptors Blog

Опубликовано: forax@univ-mlv.fr 11.01.2007
forax@univ-mlv.fr

Property and bean spec Blog

Опубликовано: forax@univ-mlv.fr 08.01.2007
forax@univ-mlv.fr

All your property are belong to us Blog

Опубликовано: forax@univ-mlv.fr 05.01.2007

Happy new year everyone.
Since my last post, i've done some homeworks :),
and i'm please to present you a new version of the prototype java compiler which includes property support.

First, why properties ?, we have already fields and any IDE have a menu item that can generate getters and setters, so why do, we need properties ?

Why do we write getter and setter ? The reason, is that when you use a property, you don't want to know if its implementation use a field or something else. By example, you can first choose to implement it as a field and later when a new feature is require change your code to use a method. To be binary backward compatible, a carefull developer will always define a getter and a setter, even if the property is a field package visible, but its a boiler plate code and i don't see a reason why we should do that if the compiler ensure that a change in the way property is written will always be backward compatible.

The compiler must handle properties for you and garantee that implementation change must be binary compatible without writing boilerplate codes.

Defining a simple property

  public class PropertyPoint {
    property int x;
    property int y;
  }
  ...
  public static void main(String[] args) {
    PropertyPoint p = new PropertyPoint(1, 2);
    System.out.println(p.x + " " + p.y);  // replaced by p.getX(), p.getY()
  }

A word about the keyword 'property', 'property' is not a real keyword like 'public' or 'enum', so you can have a variable named property in another place in your code, i will still compile, even if you create a class property, it will still compile. Basically, if the compiler found the keyword 'property' in another place, it consider it as an identifier or a type depending on its location. This example, written by peter ah

forax@univ-mlv.fr

Call me Santa Blog

Опубликовано: forax@univ-mlv.fr 17.12.2006

Since my last post, i've played with javac enought to be able to provide a patch that enables to let the compiler infers the type of local variables.

Life is a matter of choices

If you have already read the last Peter Ahé's blog entry you know that, at least, two proposed syntaxes compete.
The first one suggested by James Gosling and named 'Algol' in the prototype use ':=' instead of '=' to declare local variables. I've tweak the example widely used to explain generics and autoboxing without declaring the type of the local variables.

  // print a frequency table of words
  public static void main(String[] args) {
    map:=new HashMap<String,Integer>();
    for(word:args) {
      freq:=map.get(word);
      map.put(word,(freq==null)?1:freq+1);
    }
    System.out.println(map);
  }

Note that the compiler infers local variable in foreach loop too.

The second syntax supported by Peter Ahé and Christian Plesner Hansen use the keyword final to acheive the same goal. My running example with the 'final' syntax:

  public static void main(String[] args) {
    final map=new HashMap<String,Integer>();
    for(final word:args) {
      final freq=map.get(word);
      map.put(word,(freq==null)?1:freq+1);
    }
    System.out.println(map);
  }

How to use the prototype ?

To enable the Algol syntax, call javac in this way:
java -jar prototype-1.7-b04.jar -XDinferLocally=Algol TestAlgol.java

or if you prefer the final syntax:
java -jar prototype-1.7-b04.jar -XDinferLocally=final TestFinal.java

What you can do ?

You can test the prototype and let us know what you thinking.
Do you prefer the Algol syntax, the final syntax or none of both (perhaps because you hate the idea behind) ?

Download the prototype : prototype-1.7-b04.jar
Download the prototype patch against the Open JDK Compiler (1.7b04): patch-1.7b04

Cheers, Rémi

forax@univ-mlv.fr

Type inference of local variables Blog

Опубликовано: forax@univ-mlv.fr 10.12.2006

Фильтр по блогу

По дате: