There doesn't seem to be many aspects untouched such an approach. The
whole multi-line String discussion would become utter pointless as
would line lengths. But there would also be some interesting AOP
scenarios (which I am usually against when it comes to external
configuration and byte-code weaving) as well as design-by-contract,
post and precondition checks which could be toggled invisible etc. A
perspective tool (Mylyn) would kick @$$ too in such an editor. Is it a
pipe-dream? I really hope not.
/Casper
On 11 Sep., 04:00, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Brian, the central idea behind AST editing also involves moving the
> process of editing, rendering, and compiling into user-space. So, for
> your grid setting endeavour, you could code up a plugin or macro or
> other mechanism which knows how to render the insert instructions. And
> it would look much, much better; it would look a little like this:
>
> grid.setAllWidgets:
>
> ----------------------------------------------------------
> | new Label("User ID"); | usernameBox |
> ----------------------------------------------------------
> | new Label("Password"); | passwordBox |
> ----------------------------------------------------------
>
> except nicer looking, with actual lines and not fake ascii ones. When
> you change the grid's explicit dimensions, the table will INSTANTLY
> reflect this. In fact, you can tab/enter/some other shortcut in your
> table simile and the grid constructor call would automatically adjust
> - because what you're actually editing is a single grid set widgets
> plugin, which includes generating everything in that code snippet -
> the grid constructor, as well as each setWidget() call. The AST here
> is a custom type, the rendering and editing of which is left to the
> plugin. Where other tools need to interop (for 'find callers' and
> other such tools), the plugin reports the actual source representation
> instead of this graphical device.
>
> Are you starting to see how revolutionary such a thing would be?
>
> On Sep 10, 7:18 pm, Brian <brian.irei...@gmail.com> wrote:
>
> > There is a part of me that likes this idea (mostly the part of me that
> > has to read other people's code). The other part of me would mourn the
> > loss of the ability to express something by bending the general style
> > rules.
>
> > I've been using GWT recently and have struggled with writing clear
> > code for constructing views. What I'm experimenting with in some cases
> > is to make the code a visual representation of the layout. This began
> > with and works very nicely for VerticalPanel. In my current
> > guidelines, adding an element to a VerticalPanel is not allowed to
> > take more than one line. If it's something simple like a Label that I
> > don't need to retain access to, I just construct a new one inline.
> > Otherwise, I write a method to create the element. For example:
>
> > VerticalPanel panel = new VerticalPanel();
> > panel.add(new Label("Login"));
> > panel.add(makeLoginForm());
> > panel.add(makeLoginButton());
> > panel.add(makeForgotPasswordLink());
>
> > This also has the advantage of naming the pieces of the UI. While this
> > is also a slight burden, I'm generally in favor of it for the sake of
> > clarity.
>
> > I then applied this to a Grid. In the specific case, it was a simple
> > 2x2 grid:
>
> > Grid grid = new Grid(2, 2);
> > grid.setWidget(0, 0, new Label("User ID")); grid.setWidget
> > (0, 1, usernameBox);
> > grid.setWidget(1, 0, new Label("Password")); grid.setWidget
> > (1, 1, passwordBox);
>
> > Note that with a fixed width font, the 2nd statements line up with
> > each other. I'm not normally a fan of putting multiple statements on
> > the same line, but in this case, it makes the intent of the code very
> > clear. (The multiple statements, of course, still need to reasonably
> > fit on one line of text.)
>
> > While I'm very particular about consistent style, it's nice to be able
> > to be creative when the situation calls for it.
>
> > (BTW, I've usually preferred spaces instead of tabs, but tabs would
> > make it easier to make sure that the statements stay lined up. In
> > fact, using tabs explicitly expresses the intent for them to line up.)
>
> > -Brian
>
> > On Sep 9, 11:10 pm, Joshua Marinacci <jos...@marinacci.org> wrote:
>
> > > RANT!
>
> > > Why, in the 21st century, are we still writing code with ascii symbols
> > > in text editors, and worried about the exact indentation and whether
> > > to use tabs, spaces, etc?!!
>
> > > Since the IDE knows the structure of our code, why aren't we just
> > > sharing ASTs directly, letting your IDE format it to your desire, and
> > > only sharing the underlying AST with your fellow developers. Encoding,
> > > spaces, braces, etc. is a detail that only matters when presented to
> > > the human.
>
> > > What we do today is like editing image files from the commandline!
>
> > > On Sep 9, 2009, at 7:32 PM, Ryan Waterer wrote:
>
> > > > While experienced programmers might not worry about the braces on a
> > > > single line, they become invaluable to any junior programmers. I've
> > > > trained a few in which they couldn't understand why the following
> > > > code segment simply stopped working. (Let's not even start a
> > > > discussion about System.out.println as a valid debugging tool, ok?
> > > > This is just an example of a n00blet mistake )
>
> > > > for (int y = 0; y < lines; y++)
> > > > for (int x = 0; x < columns; x++)
> > > > System.out.println("The sum is: " + sum);
> > > > sum += cells[y][x];
>
> > > > I agree that the braces add a bit of "clutter" to the visual look
> > > > and feel of code. However, I feel that it helps with the overall
> > > > maintainability of the code and therefore, I disregard the way that
> > > > it looks.
>
> > > > --Ryan
>
> > > > On Wed, Sep 9, 2009 at 8:24 PM, Jess Holle <je...@ptc.com> wrote:
> > > > I'll agree on the newlines and indents, but the braces are silly.
>
> > > > One might debate the extra whitespace inside the ()'s, but I find it
> > > > more readable with the whitespace -- to each his/her own in that
> > > > regard.
>
> > > > TorNorbye wrote:
> > > >> On Sep 9, 5:27 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
> > > >>> Here's a line from my code:
>
> > > >>> for ( int y = 0 ; x < lines ; y++ ) for ( int x = 0 ; x <
> > > >>> columns ; x+
> > > >>> + ) sum += cells[y][x];
>
> > > >> I guess that's where we disagree.
>
> > > >> for (int y = 0; y < lines; y++) {
> > > >> for (int x = 0; x < columns; x++) {
> > > >> sum += cells[y][x];
> > > >> }
> > > >> }
>
> > > >> is IMHO better because:
> > > >> (a) I can see immediately that I'm dealing with a nested construct
> > > >> here, and that's it's O(n^2)
> > > >> (b) I can more easily set breakpoints on individual statements of
> > > >> this
> > > >> code while debugging - and similarly other "line oriented" operations
> > > >> (like quickfixes etc) get more cluttery when it's all on one line.
> > > >> Profiling data / statement counts / code coverage highlighting for
> > > >> the
> > > >> line is also trickier when you mash multiple statements into one
> > > >> line.
> > > >> (c) I think it's less likely that I would have made the "x < lines"
> > > >> error that was in your code when typing it this way because the
> > > >> handling of y and x were done separately on separate lines (though
> > > >> this is a bit speculative)
> > > >> (d) I removed your spaces inside the parentheses, because they are
> > > >> Bad! Bad!
>
> > > >> (Ok c and d are padding)
>
> > > >> I am -not- looking to minimize the number of lines needed to express
> > > >> code. If I wanted that, I'd be coding in Perl. I deliberately add
> > > >> newlines to make the code more airy and to group logical operations
> > > >> together. I always insert a newline before the final return-statement
> > > >> from a function etc.
>
> > > >> I think the extra vertical space you've gained, which arguably could
> > > >> help you orient yourself in your code by showing more of the
> > > >> surrounding context, is lost because the code itself is denser and
> > > >> more difficult to visually scan.
>
> > > >> Oh no, a formatting flamewar -- what have I gotten myself into?
>
> > > >> -- Tor
>
> > > >> P.S. No tabs!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
