On Sun, Sep 13, 2009 at 11:20 PM, Joshua Marinacci <[email protected]>wrote:
>
> not if we find a way around the chicken and egg problem.
>
> brainstorm: assume a projection based system and no backwards
> compatibility issues (an IDE and SCM and code review tool etc.
> magically exists which supports the new system): then you could do:
>
> * locked blocks. Parts of your code should be freely refactorable.
> Other parts should be offlimits, except for special occasions. Your
> SQL statements, for example, since they correspond to something
> outside the code system (ie: the database). What if you could mark
> some blocks as locked so that they wouldn't be refactorable and would
> give you a warning when you try to do so. You could still unlock it if
> you decide it's what you really want to do, but this gives you
> protection against accidental changes. This is really just some
> metadata stored on the blocks which editors agree to respect so that
> you don't shoot yourself.
>
But this could be possible in the current Java (and would be even better if
one could annotate blocks)
@Lock
{
//My horrid, fragile, code
}
And you can't edit anything withing the block unless you remove the
@Lock-annotation...
I like it
>
> * postit notes: store notes to yourself and other developers in the
> source. We do this today with comments, but it could be made more
> rigorous, searchable, nicely highlighted etc. And you can make them
> invisible when you don't want to see them anymore.
>
> * inline unit tests. Why are your unit tests in a separate class. It
> should be easy to put the test for a method right next to the method,
> and hide it when you don't want to look at it. the test is stripped
> when you compile for deployment.
>
> * optimizations: creating optimizations as part of the compilation
> step used to be the job of the compiler, but if you have a standard
> AST format that is fed into the compiler then you could easily build
> lots of cool optimizations between the code editor and the compiler,
> rather than inside the compiler itself. This opens up such
> optimizations to a much wider audience than just compiler hackers. I
> expect we'd see a Cambrian Explosion of extensions and optimizations
> very quickly.
>
> - j
>
> On Sep 10, 2009, at 7:30 PM, Casper Bang wrote:
>
> >
> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> >>>>>> 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!
> > >
>
>
> >
>
--
Viktor Klang
Blog: klangism.blogspot.com
Twttr: viktorklang
Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
