Annotations remain illegal on code blocks. This is a real shame, as I
could do some fun tricks with lomboks. In fact, it's such a shame, I'm
fairly sure lombok will evolve fairly quickly to hacking the grammar
so you CAN in fact annotate raw code blocks :)
In other words, @Lock { statements; } <- illegal java code now, and
even after the java7 language change (not sure if it's a definite go,
it has been in the plans for a while now) to relax the limitations on
where annotations are allowed to go.
NB: Letting the simpler unit test be a sticky note attached directly
to the method they test: Sheer genius.
On Sep 14, 8:43 am, Viktor Klang <[email protected]> wrote:
> 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...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
