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; } <-
On Mon, Sep 14, 2009 at 2:22 PM, Joshua Marinacci wrote:
>
> Not necessarily. The extension could be defined in such as way that it
> turns into an external class. We just need to get away from the idea
> that one text file == one class.
HALLELUJAH!
PRAISE THE LORD!
> One concept deals with b
Not necessarily. The extension could be defined in such as way that it
turns into an external class. We just need to get away from the idea
that one text file == one class. One concept deals with byte storage,
the other deals with compilation and logical units. They really have
nothing t
>
> 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 agai
On Sep 13, 10:20 pm, Joshua Marinacci wrote:
> * 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
On Sun, Sep 13, 2009 at 11:20 PM, Joshua Marinacci 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
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
On Fri, Sep 11, 2009 at 14:24, Vince O'Sullivan wrote:
>
>
>
> On Sep 11, 11:11 am, B Smith-Mannschott wrote:
>> Kids these days think they're so brilliant! We were doing this before
>> their parents were in diapers!
>>
>> - A decent lisp-aware editor (e.g. Emacs)
Yea. Emacs is not for everyone
On Sep 11, 11:11 am, B Smith-Mannschott wrote:
> Kids these days think they're so brilliant! We were doing this before
> their parents were in diapers!
>
> - A decent lisp-aware editor (e.g. Emacs)
I think you just summed up the Lisp community and alienated everyone
born after 1950 in one go!
Time to push for a macros facility for Java 8/9/10?
B Smith-Mannschott wrote:
> The whole Lombok discussion has been fascinating. I really like it and
> I think it's a clever hack. The discussion of how it works (by
> rewriting java parse trees) has given people lots of ideas about how
> this ide
Speaking of AST based editors/languages, has anyone here used Jetbrains MPS
at all? The whole editor is AST based, with extendable, composable
languages.
I keep meaning to give it a bash but never find the time.
--
Pull me down under...
On Fri, Sep 11, 2009 at 10:08 PM, B Smith-Mannschott
wro
On Fri, Sep 11, 2009 at 12:08, B Smith-Mannschott wrote:
> - A Lisp program is just the written form of a data structure.
>
> - The semantics of the language are defined not in terms of what the
> syntax means, but in terms of what a particular arrangement of those
> data structures means.
>
> -
The whole Lombok discussion has been fascinating. I really like it and
I think it's a clever hack. The discussion of how it works (by
rewriting java parse trees) has given people lots of ideas about how
this idea could be taken farther. But...
Any such discussion of syntax rewriting, and extendin
On Fri, Sep 11, 2009 at 4:30 AM, 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 ag
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 wea
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, m
Well, every closure proposal, including BGGA, are written so that a
prototype can be made (or in the case of BGGA, exists!) that runs on a
plain jane vanilla JVM 1.6. Almost all of the heavy lifting BGGA does
can technically be represented in vanilla java source, though it'll be
unwieldy, ugly, an
Joshua Marinacci wrote:
> Still, I think one day we will move towards this. I can't imagine the
> computer in the Starship Enterprise was coded in text files.
>
Yes, I mean writing has not been around that long compared to
computers. I am sure its just a passing fad.
Alan ;-) ;-) ;-)
--
that's an interesting article. I'm glad to hear I'm not the only one
who's thought of this. That shows it's not crazy, just very hard to do
(for compatibility reasons as he states).
Still, I think one day we will move towards this. I can't imagine the
computer in the Starship Enterprise wa
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 co
More importantly, they add regularity.
The only semantic difference between:
if (expr)
doThing1();
and:
if (expr) {
doThing1();
doThing2();
}
is an extra statement. So why should the syntactic difference be
greater than that?
-- Tim
On Sep 10, 5:32 am, Ben S
Thanks Ben, had not heard of this, apparently called "projectional
editing":
http://www.martinfowler.com/bliki/ProjectionalEditing.html
The videos does indeed resemble Stephen Hawking navigating his voice
synthesis software but I'm sure that could be done better than that.
It looks and feels as
> I'm not sure why you'd have to use your mouse. Everything I'm
> imagining would be done in the IDE with keystrokes.
Because the semantic differences achievable by changing just a few
characters is so vast that you will have a hard time coming up with
shortcuts for every one of them. Ultimatel
On Sep 10, 2009, at 8:15 AM, Reinier Zwitserloot wrote:
> In an AST based editing environment, this problem goes away. At write
> time you must of course have the plugin available to you, at which
>
Not necessarily. If the AST spec was written correctly you could have
some sort of extensible bl
yep. Essentially these are all things which IDEs and addon tools are
trying to do today, but do imperfectly because they are operating on
an array of ascii text (or unicode if it's Java). As always, getting
from here to there is the hard part. :)
On Sep 10, 2009, at 8:42 AM, Casper Bang wr
2009/9/11 Joshua Marinacci
> On Sep 10, 2009, at 8:48 AM, Ben Schulz wrote:
>
> >
> >>> Youv'e got to write IDE support for this. Building this new language
> >>> requires also building an IDE plugin that understands it".
> >>
> >> And that probably explains why it hasn't been done before, a chic
On Sep 10, 2009, at 8:48 AM, Ben Schulz wrote:
>
>>> Youv'e got to write IDE support for this. Building this new language
>>> requires also building an IDE plugin that understands it".
>>
>> And that probably explains why it hasn't been done before, a chicken
>> and egg problem.
>
> Ah, but it h
> > Youv'e got to write IDE support for this. Building this new language
> > requires also building an IDE plugin that understands it".
>
> And that probably explains why it hasn't been done before, a chicken
> and egg problem.
Ah, but it has been done before.
http://lambda-the-ultimate.org/node
It really is just another example of extending the compiler into
"userspace", much like FindBugs and Lombok. Not only should it provide
better error messages, refactoring suggestions and optimizations but
it would index also compile much faster - the compiler would be handed
an AST that can be ass
> The potential to use different keywords, line terminators, and other
> syntax of your choosing and have it be completely isolated to your
> environment. No other developer is affected".
Microsoft already "pioneered" that, a VBA macro in Danish would use
"Hvis" rather then "If". ;)
> Youv'e got
In another thread, the idea of compiler-plugin based literals was
floated. I observed that unless that plugin is available at tokenize
time (which means, before resolving typing info, so that's annoying,
as you'd want to use that to figure out which plugin is responsible),
the compiler can't conti
I suspect you are right. I've asked this question of many people and
gotten a variety of reasons why it won't work. They reasons are always
valid, but they always boil down to the same thing: compatibility
with existing systems. If we could start over fresh *for everything*,
then I think
Thanks for those links, that's very close to what I had in mind. I
have dabbled on a plugin like that for NetBeans in the past but 1) it
was too slow and 2) it no longer works due to NetBeans API changes.
But seeing this makes me wanna give it another go.
/Casper
On 10 Sep., 07:06, B Smith-Manns
> Ben Schultz: They add clutter.
I reject your premise. They don't add clutter, they add structure. If
you disagree, that's fine, just stop telling people that they're doing
it wrong, it's condescending and solely based on your opinion.
With kind regards
Ben
--~--~-~--~~~
And it alls starts with the language specs still being written at the
abstraction level of a concrete syntax. Chapter 1: Tokenization.
Peter
Joshua Marinacci wrote:
> RANT!
>
> Why, in the 21st century, are we still writing code with ascii symbols
> in text editors, and worried about the ex
I think the best way to indent is to have the braces on separate lines
and indentation levels and then put semicolons after the tabs to make
the indentation level more visible:
for (int y = 0; y < lines; y++)
{
;for (int x = 0; x < columns; x++)
;{
;;sum += cells
Well...
For starters, stack traces report against line numbers and line numbers
are meaningless is you can't agree on what's on which line.
Once this was solved or even limiting oneself to formatting within a
line, it might be nice if indentation and formatting would be just while
one was edit
Or, if they are using eclipse, configure it to format the source
whenever it's saved. And if you want, it'll even add the extra braces
for you automatically.
On Sep 10, 5:13 am, Reinier Zwitserloot wrote:
> You're doing it wrong, Ryan.
>
> You should teach them cmd/ctrl+alt+f, and you should te
Wow - my post got hijacked :-)
p.s. Disclaimer: 'SpikyOrange' was cross referencing someone elses
blogg, they were not my views ;-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to
Jess Holle wrote:
> Peter Becker wrote:
>> I have heard of (and from) many people involved in the development of
>> relational databases and/or the SQL standard who regret the introduction
>> of NULL. Codd wanted it replaced with two distinct values, Date called
>> them "a disaster". IIRC Jim M
Two points
1/
I agree with the mandatory use of braces because of the "Insert one
more line in the if statement and get a completely different outcome
problem". The potential negatives of that are so significant, its
worth any noise.
2/ The JavaFX plugin for Netbeans currently lacks a code fo
But do you use tabs or spaces to ident your braces ? :D
On Thu, Sep 10, 2009 at 7:00 AM, TorNorbye wrote:
>
> I have found bugs in code even from experienced programmers that
> boiled down to a incorrect usage of an if block which would not have
> happened with braces.
>
> That's why I insist on
On Thu, Sep 10, 2009 at 03:50, Casper Bang wrote:
[snip]
> I often think there must be some neat visual way to show nesting and
> scoping better than we do today, i.e. by drawing a frame around,
> drawing with a darker color or so.
[snip]
xcode 3.0 and later provides something like this under th
If you edited ASTs directly, lombok would become a few orders of
magnitude simpler, and that's not the only thing that would simplify.
Still, I have yet to see a proper execution. If lombok wasn't possible
and to make this happen I'd have to roll an IDE from scratch, I'd (A)
be mentally unstable,
You're doing it wrong, Ryan.
You should teach them cmd/ctrl+alt+f, and you should teach them that
the editor knows better than they do, so if it indents things 'funny',
then their code is broken. "Solving" their lack of understanding by
indoctrinating them with the 'braces' everywhere mantra is a
I have found bugs in code even from experienced programmers that
boiled down to a incorrect usage of an if block which would not have
happened with braces.
That's why I insist on using it, and insist on it from my coworkers.
When used uniformly your brain learns to recognize braces as block
delim
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 t
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.printl
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 wrote:
>
>> Here's a line
In a word, "yuck".
I'll skip braces but not newlines or indentation -- I quickly get lost
in stuff like this of my nemesis
if ( foo < bar ) baz( bar ); else baz( foo );
all on one line -- again, yuck.
Reinier Zwitserloot wrote:
> Here's a line from my code:
>
> for ( int y = 0 ; x < lines ; y+
YES! Casper brought tabs into it! Wahoo! We've got all the ingredients
here to beat the post count of the checked exception thread. It ran
for over 150 posts. Can we beat it?
I'll toss this one into the ring:
The ONLY right indentation scheme is to use tabs for indentation and
spaces for spacing
Oh, no, Tor. Not a formatting flamewar. It must be a slow day.
I know the inner spaces thing is bad. I decided on it years and years
ago, I've since recanted from my evil ways, but the damn things are so
stuck in my muscle memory I can't get rid of them. Horrible situation
to be in.
Sure, squash
I agree with Tor, except drop the braces:
for (int y = 0; y < lines; y++)
for (int x = 0; x < columns; x++)
sum += cells[y][x];
It reads just as easily and there's a reason why we already indented
the code (with a since tab rather n spaces; how an indentation is
rendered is really up
On Sep 9, 5:27 pm, Reinier Zwitserloot 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++) {
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];
all on one line. Perfectly fine in my book. Its less than 100
characters in length, all variables are sensibly named, and the entire
operation 'feels' like a single operatio
Hit 'reply' on the wrong post - SpikyOrange specifically insinuated
curly-brace-free if statements are an abomination. To which I say:
pah!
Ben Schultz: They add clutter. Therefore, the onus is on you and not
on me - you need to prove why they are worth it. It would be silly to
ask me to prove wh
Typo, should be 50%
Unless you do:
If(...)
{ ... }
On Sep 9, 2009 6:18 PM, "Ben Schulz" wrote:
> You lose 60% vertical overview.
Great stat, how do you figure?
With kind regards
Ben
--~--~-~--~~~---~--~~ You received this
message because you are subs...
--~--
> You lose 60% vertical overview.
Great stat, how do you figure?
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 javaposse@googlegro
that gives me a sad
On Sep 9, 2009, at 9:15 AM, Casper Bang wrote:
>
>> Plus it's uniform!
>
> Well the old Sun conventions tried to. Funny enough, I have not seen
> code like this:
>
>switch(myInteger){
>case 65:{
>// Handle int = 65
>}
>}
>
> /Casper
> >
--
> Plus it's uniform!
Well the old Sun conventions tried to. Funny enough, I have not seen
code like this:
switch(myInteger){
case 65:{
// Handle int = 65
}
}
/Casper
--~--~-~--~~~---~--~~
You received this message because you a
I agree with that, it's unnecessary unless when nesting and subject to
the danging-else trap. I just wish this was more consistent in the
compiler, i.e. reflection and I/O code could be made to take only 50%
of the space if try-catch-finally would honor the same single-
statement rule as elsewhere
On Wed, Sep 9, 2009 at 6:03 PM, Ben Schulz wrote:
>
> Mind my asking what you gain? Preferably something that does not fall
> into the - arguably subjective - category of esthetics? Because if you
> got nothing, then what's wrong with adding the braces? I find they
> look dashing. Also they let m
Mind my asking what you gain? Preferably something that does not fall
into the - arguably subjective - category of esthetics? Because if you
got nothing, then what's wrong with adding the braces? I find they
look dashing. Also they let me see - at a glance - whether it's a
block or a line that's i
I think you meant to reply to something else as I never mentioned braces.
Moreover I really, really dislike having braces around single line if,
else, for, etc, blocks -- and never do in my code. I agree, that an IDE
and reasonable indentation should show the error in your ways -- rather
than
If you're scared of creating bugs due to a lack of braces (e.g. you
add a line and the code is not properly indented), you're doing it
very very wrong. That should not be a worry in a proper development
environment.
auto-format is your friend.
--Reinier "I have loads and loads of single stateme
Casper Bang wrote:
>> I'm not sure what you mean. There are no annotations in JavaFX
>>
> Sorry, from an earlier entry I inferred that there were
>> It's enough to drive one absolutely batty.
>>
> So is JDBC's index-by-1 nature in bind variables.
>
Agreed! Everything else in Java is i
> I'm not sure what you mean. There are no annotations in JavaFX
Sorry, from an earlier entry I inferred that there were.
> It's enough to drive one absolutely batty.
So is JDBC's index-by-1 nature in bind variables.
--~--~-~--~~~---~--~~
You received this mess
Peter Becker wrote:
> I have heard of (and from) many people involved in the development of
> relational databases and/or the SQL standard who regret the introduction
> of NULL. Codd wanted it replaced with two distinct values, Date called
> them "a disaster". IIRC Jim Melton had some negative c
I have heard of (and from) many people involved in the development of
relational databases and/or the SQL standard who regret the introduction
of NULL. Codd wanted it replaced with two distinct values, Date called
them "a disaster". IIRC Jim Melton had some negative comments, too:
http://www.s
On Sep 8, 6:57 am, SpikyOrange wrote:
> get over that. For me it is as confusing and dangerous as when someone
> uses an if statement in Java without curly braces. I mean, c'mon, it's
> only a couple of braces ("it's only a return statement..."), but the
> danger of maintaining that code incorrec
I'm not sure what you mean. There are no annotations in JavaFX. The
language tries to prevent you from doing bad things, like nulling a
boolean. Preventing errors beforehand is one of the core philosophies
of JavaFX Script.
- Josh
On Sep 8, 2009, at 7:04 PM, Casper Bang wrote:
>
> Take al
Hi Tor,
> I posted a comment on the blog, but I don't see it there so I may have
> done something wrong.
Many thanks for your comments, I've added a link back to this forum
post for now - it might have been intermitted because someone else
managed to post a comment.
> 1. The return type of a fu
Um, unless I'm mistaken, there are no annotations in JavaFX.
Unless its undocumented, in the (as yet incomplete after nearly 12
months) language reference.
http://openjfx.java.sun.com/current-build/doc/reference/JavaFXReference.html
On Sep 9, 12:04 pm, Casper Bang wrote:
> Take all paths simul
Take all paths simultaneously, a la the qubit? ;) No for language
constructs that obviously wouldn't make sense which is why in C#
you'll get a compile error unless you cast bool? to bool. If that cast
is done on a bool? set to null, you'd get what amounts to a
ClassCastException in Java.
I wonder
while nullable booleans make sense when you are talking about data
storage I don't think they make sense in one of your general purpose
programming constructs. For example, if boolean could be null, what
does the following code mean?
var b:Boolean = null;
var t:Boolean = false;
if(b) {
Have you checked out Scala? They have several variations of Null,
null, nil, Nothing, None and perhaps more that I am unaware of. And in
C# there's language support for the notion of a Nullable, basically
automatic wrapper classes in the form of something like:
struct Nullable{
public bool ha
These were great posts - thanks guys.
It's interesting that you mention databases in relation to nulls,
because this is where I've historically had to deal with null Booleans
and suchlike. Usually it's as you describe - the entries are nullable
and therefore I need to do something different in t
Boolean is really just an Enum that can be True and False isn't it?
I'm guessing a modern day version of Java would've implemented them as
such. Then it would be no problem representing a tri-state, quad-state
or whatever.
The problem with null is that we end up with so much testing which
obscures
Clumsy finger sent last e-mail too soon.
To finish my last sentence
I can see that maybe one need @Nullable Boolean to tell the JavaFX
compiler that this should not be a simple "boolean", but I cannot see
discarding a built in way of denoting true/false/null in one data item.
Jess Holle wr
I've always found the whole endless debate over "null" treatment that
I've seen here and elsewhere odd.
In databases most everything is nullable unless explicitly stated
otherwise -- and there's good reason for this. There are really good
use cases for true/false/null tri-state data -- and sim
It's also important to point out that the compiler rejects null for a
Boolean because null simply isn't a valid value for a boolean (in the
abstract mathematical sense of 'boolean'). Booleans can be true or
false. That's it. The compiler rejects anything else. The same for
Numbers. The co
I posted a comment on the blog, but I don't see it there so I may have
done something wrong.
In any case, as far as I understand things (from using the language -
I'm not working on the compiler team)
1. The return type of a function, if it isn't specified explicitly
(either here or in the funct
82 matches
Mail list logo
