Syntactose Proof Of Concept

What would it be like if syntactic sugar was implemented in the IDE instead of in the language?

For a sneak preview of how this concept might feel in practice this Netbeans Module is a (barely functional) proof of concept for Properties using this approach.

Installation

To try it out download the netbeans module above and install in netbeans (tested with 6.1 and 6.5).

Operation

Start a new java class.

Enter a property by typing (it starts with a back quote character)

`Property String name;

The plugin will treat this like a template and expand it to a field, getter and setter, then immediately create a fold around it and collapse the fold so that it looks just like the sugar form you typed.

Close the file and reopen it. The property is collapsed. Collapse and expand the fold. Enter some more properties using the sugar.

If the field and accessor are not adjacent in a class, there are two folds, and they are synchronised, but its not quite as nice as the single fold when they are adjacent.  Open an existing source file with getters and setters and have a look.

Expand a property and edit the type of the field. The folds should disappear because the code no longer matches the pattern for the desugared form. Change it back and the fold will be reinstated and collapse automatically.

Internals

This is a barely functioning proof of concept, using existing netbeans facilities.

The components of a property (field and methods) get folded into a single Property statement in the view. There are multiple folds but they need to collapse / expand as one so the folds are linked so that they are either all collapsed or all expanded. Also if you type a Property statement (say `Property String fname;) into the editor, the plugin will desugar it into a field and accessor methods, then the fold logic will fold it back into what you typed. While this is in no way a polished implementation it does prove the concept.

Weaknesses

The sugar detection is done when the cursor is immediately after the ; so if you prefix an existing field declaration with
`Property
then it won't detect it unless you then move the cursor to just after the ; (and then only if there is only one field in the declaration).

The sugar detection uses regular expressions, not a decent parser so for example entering a type with spaces (possible with a generic type) will probably screw it up. Remember its only a proof of concept.

Sometimes the folds can get out of synchronisation and generally screwed up. The code is fine, and the fold state can often be recovered using the collapse all folds in document function. Otherwise closing and reopening the file tidies up.

The fold logic only considers the field name and type, and the accessor method signatures, not the bodies, so if you have accessors that access a different field from the one suggested by the naming conventions, the plugin will get it wrong.

Editing the collapsed form (either type or name) doe not update across the field and accessors which it ought to. It just edits the field, and then there are no matching accessors so the fold disappears. Just pretend that you could edit the sugared form and have the accessor signatures follow the same changes.

This particular sugar was hand coded, a real prototype would allow users to define their 2 way transforms in some DSL. For a taste of what that could be like, Jackpot is interesting.