True, I'm known to overpromise. But this is no pipe dream. Just
putting the finishing touches on it. It's not bijective so far, but on
the plus side the effort required to change your eclipse is minimal,
and you don't need to change your javac at all. Thank you, annotation
processor API!
I explicitly haven't added property support YET, because there are so
many ways to get there.
Imagine, for a moment, you could add properties to the language, but
you must adhere to the following rule:
RULE: All new code forms (including declaring a property, declaring
the properties (heh) of a property (does it have getters or setters,
names of things, type, yadayada) and operations on properties (such as
binding 2 properties together, or adding a hook to a property for when
it changes) must all be 'superficially' legal current (1.6) java.
With superficially, I mean: A tree parser would do a passing job at
turning this java-like code into a vanilla java AST. Syntax errors are
okay. I'll highlight what I mean with an example:
int foo = { System.out.println("code block?"); 5; }
The above is not going to work, because javac AST parsers (at least,
both javac's and eclipse's) are fundamentally not going to expect code
blocks in use as an expression. On the other hand, this:
int foo = next; {
System.out.println("code block?");
5;
}
*WOULD* work; next is an identifier (it's perfectly okay if there is
no variable, field, or type name in scope with the name 'next', an AST
parser doesn't even know about such things. It just knows about
identifiers; linking identifiers to actual variables/types is done
later and is called 'binding'. We're in the pre-binding phase here.
The semi-colon means a new statement is going to follow next, and you
can legally stick a code block in place of a statement anywhere in
java. The lone '5' is a compile time error (only certain expressions
are legal as statements, and that isn't one of them, but an AST parser
is nevertheless going to create some sort of placeholder for it and
generate an error on it, which is close enough to the mark). Of
course, one could argue that the above snippet is far too mystical and
cumbersome to be worth it (and I would probably agree with you).
So, given these constraints, how would you do properties?
Here are a few ideas:
Approach #1: property annotation + static vind method.
DECLARATION: private @Property int x;
EFFECT: Creates getter, setter, field to store
propertychangelisteners, and an addXListener and removeXListener
method to register/deregister listeners. Setter will insert call to
fire all listeners.
BINDING: SomeUtilClass.bind(instanceWithX, "x", this, "y");
With the string literals actually compile-time checked (if you typo a
property name, you'll get a red wavy underline in your IDE right
away).
Approach #2: Property class that wraps fields.
DECLARATION: private @Property int x;
EFFECT: Creates a Property<Integer> typed field named "$x", which has
a getter and setter method that 'pass through' to the real getter and
setter that you can write yourself (or if you omit them, actually set/
get this field), as well as hosting methods to add/remove listeners.
BINDING: instanceWithX.$x.bind(this.$y);
It would also be nice to be compatible with e.g. javaFX's properties.
What happens internally when you bind 2 fields together in javaFX?
Clearly it has to rewrite foo.x = value; calls to some sort of setter
call, so that the other variable (ostensibly registered as
propertychangelistener or some other sort of listener) can be
notified. How does threading work? Does the actual notification occur
in the EDT, or in the same thread as the one making the change to one
side of the bound relation? (I read somewhere javaFX will move almost
everything into the EDT for you so you don't have to worry about pesky
SwingUtilities.invokeLater calls).
On Jul 7, 11:15 pm, Ben Schulz <[email protected]> wrote:
> On 7 Jul., 22:03, Reinier Zwitserloot <[email protected]> wrote:
>
> > What I would like to see:
>
> > private @Getter int x = 5;
>
> > I don't really need the C# feature where you can write the getter on
> > location; most getters just return the value, and as long as the API
> > works via a getFoo() call (and not via accessing a public field!) I
> > can always change it later.
>
> I said I was dreaming, bubble-burster! :P
>
> Incidentally: I noticed I made IllegalAccessException-mistake in my
> previous post. If anyone cares about my dreams:
> private final Binding binding
> = BindingLib.createBinding(
> this#width#set, // the #set was missing
> parent.width - 20
> );
>
> > Incidentally, I may have an announcement to make soon for those who
> > like this idea :P (though IDEA and Netbeans people are going to be a
> > bit disappointed...)
>
> By now I barely have to guess what it's gonna be. Some sort of
> bijektive transformation over parse trees to get eclipse users quasi-
> properties and quasi-CICE without actual (Java) language support.
> Being an eclipse user (don't fillet me, I'm just too lazy to switch) I
> will have a hard time to overstate my satisfaction, but you have yet
> to prove that the cake is in fact not a lie.
>
> With kind regards
> Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
