On 25.03.24 21:17, Caleb Brandt wrote:
[...]
If you do
class X {
String foo = "bar"
get() { return this.foo; }
set(x) { this.foo = x; doSomethingElse()}
}
then the call to doSomethingElse is on line 4. But what will happen if
the IDE find doSomethingElse does not exist and wants to mark the call?
If the IDE works on the Java code for this the position will be wrong.
Yes, you would get an error message that is fitting as in
"soSomethingElse not found"... maybe even the correct line. This means
your IDE would have to know how to translate back to the code you
actually wrote. That is why this probably ends up as extension for the
compiler... which the IDEs may or may not support. I think Manifold is
doing that.
We all know what a getter and a setter is, so condensing them into one
place is easy to understand.
Sure, then I can write
private String foo = ("bar", {->this.foo}, {x->this.foo=;
doSomethingElse()})
And you will totally understand... right.. right?? I mean there are so
much in one place, you can barely compress this more and still write the
code. Well.. to get more serious again. You should not underestimate the
challenges of language design. And yes, this can be as bad as: "eh... it
is using begin/end instead of curly braces? Nah, don't like it".. "why
are there no blocks? There are? Oh the space is significant for this!?".
And I am not kidding. the first Is a C-guy disliking anything Pascal,
the second is all about Python.
But what's a "closure"? What's a
"delegate"? What's a "virtual thread"??? (I'm kidding.) People don't
have a basis for these things in Java, so it's just /more/ stuff to
learn instead of already making sense to a Java-only programmer.
closures are quite similar to lambdas. The delegate concept is not the
difficult part. The difficult part is that you attach a code block to a
method and then the method does something with the code block. Ah yes...
conceptually those lambdas are also very near to anonymous inner
classes. A concept existing in Java for a long time already. It is all
about the approach really. Of course if the people you are showing this
are not open to the concepts and different views, then you can forget
about it. I for example never discuss with people about static
compilation if I get the impression they are thinking the false security
of static compilation solves all their problems in life.
[...]
Every addition needs to scan like Java at face value and
feel like something Oracle themselves would have added.
With lambdas they did quite the style break in my opinion. They did it
before though... with enums for example. And don't get me started about
generics or the switch-case. I really doubt I would be able to tell of a
new feature if it is as if Oracle themselves would have added it. In the
end that is not the key-point. It is how the new features work and look
together with the overall language. For example we had a feature request
to support "statement if expression", meaning "if (expression)
statement". Which exists in some language, but we decided against,
because it does not fit the style of the Groovy language.
[...]
_*1. WE CAN USE JAVA'S TOOLS*
_
Yeah so remember what I said about how "nothing will ever match Java in
a Java space"? If you can't beat 'em, join 'em. By acting as a
transparent frontend to real Java source code, we can leverage existing
Java analyzers to do our linting for us.
But it is not fully transparent. It is one-way.
The IntelliJ system already
has a variant of this for CLion's macro processing, being able to detect
errors in the applied macro and display the code it'll be replaced with
in a hover popup.
But the preprocessor in C/C++ was made part of the compiler even though
it originally existed and was intended as independent tool. It just did
not work, because of the line numbering being messed up. Back in the day
there existed quite a few languages that transpiled to C, all of them
got eventually their own compiler. In the word of gcc for example you
have many languages that compile to shared representation in memory,
which is then actually compiled to the target platform. This way you
have a front-end for Modula and one for C++, but lots of the back-end
part is still the same. In the end it is still like transpiling to C,
just on a different level, where the source does not matter.
We can also use Java debuggers to their fullest extent too: it'll link
to the processed Java8 sources when we freeze on a breakpoint instead of
the J+ sources, but once again that's a /feature/, not a bug. With a
good enough formatter on the processor, they'll even thank us for it.
For this there is actually support in the Java bytecode world. If the
IDE can figure out from the file name attribute and the class name what
file to open, then the correct position in that source can be opened.
In your case the opened source would have to be the generated Java
source, since the IDE would not automatically know how that position
translates to a position in J+ sources.
[...]
No Java syntax rules are broken either - nothing new goes outside a
method, for starters - so any community-made Java source plugins will
work exactly the same on the unprocessed source as they would on the
vanilla source.
I think your getter/setter sugar has potential to break this.
String foo = "bar";
get() {
return foo;
}
set(newVal) {
foo = newVal;
doOtherThing();
}
If I let Javadoc process this, it will not see getBar and setBar, it
will see get() and set(newVal), probably getting a fit other the
variable not having a type. And if you have multiple properties you will
have multiple set and get method with very equal signatures. Many tools
will not expect that, since that is not valid Java syntax.
[...]
People won't have any excuse /not/ to use it.
People have excuses for still using Java8. I myself hated generics so
much I tried to avoid using them for many years whenever possible. And I
still try to use them sparingly.
bye blackdrag
